Tiny Core Base > TCB Q&A Forum
Rsyslog not working
CentralWare:
@andyj: IF there's a default config file at the author's website, I find that's a great place to start. (Think of MySQL or PHP - theirs are like having the entire manpages in a single document.)
1. Your .info file should state "...the enclosed /usr/local/etc/filename.conf is for testing only, it is not guaranteed or expected to suit your specific needs." The .info should also state what defaults are implemented, if any, and which files to edit should they wish to make such changes.
When possible, add a link to .info pointing to help, install or "how to" pages at the author website. Make .info do your bidding! Our jobs are not to teach people the basics of computing... or Linux itself (though we find ourselves doing no less at times) and even with the mainstream repos out there... help the masses as best you can, preferably with one or two attempts. For the Joe Schmo who wants this and that and the other thing which are very specific and helpful mostly just to them... we call those individuals "clients" depending on the circumstances.
2. The config(s) you do choose to enclose, just make sure that with those files, the application(s) start without error and can be tested using those configs. They may not do what the user wants to do in the end... but there's no way to know what exactly that would be and they would be a great starting point as opposed to nothing at all. I lean toward averages - out of the next 100 people, these features/functions are usually requested by most... and set up configs to match.
--- Quote ---You can please some of the people, some of the time...
--- End quote ---
MariaDB example: Just have it configured to use path=/home/tc/mysql user=tc group=staff and have tce.installed just mkdir -p /users/tc/mysql if it doesn't already exist -- the user can alter the defaults as they please. Me, personally, I also run a check to see if the default mysql database was created; if not, run the basic initialize from /usr/local/etc/init.d/mysql.sh or mariadb.sh (this is also done with init.d files from Fedora, CentOS, RHEL and others so it tends to be accepted and sometimes appreciated. The goal here is to offer our users building blocks that work out of the box... and allow them to modify these OOBs to suit their specific desires. The Mods they implement tend to be what's most useful for the community to chip in with advice as long as there's a common starting point.
3. If and when there's a user who complains an extension isn't configured just the way they want it to be, point them to the .info file. If you've spent time helping someone set up a configuration, put the forum URL in the .info file! People helping people get stuck repeating themselves more than anything. Make your efforts truly worthwhile. If over time there's 20 people we've helped in this fashion... put 20 links in the .info file! Some of our users actually READ those .info files before installing!! SOME. Not enough... but some! :)
Take care!
Rich:
Hi CentralWare
--- Quote from: CentralWare on October 06, 2024, 09:06:45 PM --- ... The config(s) you do choose to enclose, just make sure that with those files, the application(s) start without error and can be tested using those configs. They may not do what the user wants to do in the end... but there's no way to know what exactly ...
--- End quote ---
And that's why some extensions contain .conf.example or .conf.sample
files. I think a .conf file with an .example or .sample extension tacked
on to the end makes it clear it's not meant to be plug and play.
Stefann:
Andyj,
I actually DID read your example, not copied it blindly, concluded that your "module(load=" directives were essential the same as the "$ModLoad" syntax I'm using.
And you helped me because I noticed you included a "workdirectory" directive I did not have.
So,.. thanks again :).
With that said...
Before even posting here I got my input from a sample at GitHub: https://github.com/rsyslog/rsyslog/blob/master/sample.conf
The big annoying thing....
- Eventually I got it working by adding the global directives on "workdirectory" and/or "imuxsock"
- The sample file however does NOT include them, not mentions them, no information on essential global directives.
So,.. yeah,... it's of coarse open source and depending on the sweat of volunteers. I guess they have focussed on explaining "functionality" and have the "essentials to get it lightened up" a bit undervalued. The whole section on explaining global directives is quite minimal.
(and there is probably an other sample configuration to there that has it, but I used a lot of google and could not find it)
Stefann:
Bad... rotate script is not working
As far as I can see it's a bug in Rsyslog
Because I see same behaviour as here: https://github.com/rsyslog/rsyslog/issues/4879
==> I however do not see how that got resolved (its just closed without resolution)
I try to rotate the error log by setting an out channel with a file limit and rotate script:
--- Code: ---$outchannel debug_log,/var/log/errorlog.txt, 1000, /var/log/./rotate_debug
with rotate_debug like below:
tail -n 1 errorlog.txt > error.tmp
mv -f error.tmp errorlog.txt
--- End code ---
However: rotate_debug does not get called
Inspird by above bugreport I tried:
--- Code: ---$outchannel debug_log,/var/log/errorlog.txt, 1000, rm /var/log/errorlog.txt
--- End code ---
which indeed removes the log, but than I have nothing left (I would like to have the old one copied
I tried various alternatives without success:
--- Code: ---$outchannel debug_log,/var/log/errorlog.txt, 1000, sudo /var/log/rotate_debug
$outchannel debug_log,/var/log/errorlog.txt, 1000, 'sudo /var/log/rotate_debug'
$outchannel debug_log,/var/log/errorlog.txt, 1000, mv /var/log/errorlog.txt /var/log/errorlog.txt.rot
--- End code ---
looking into the Rsyslog debugging shows:
--- Code: ---0384.246797798:main Q:Reg/w0 : srutils.c: exec program ''sudo' /var/log/rotate_debug'
0384.294856440:main Q:Reg/w0 : glbl.c: waitpid for child 9275 returned status: 100
0384.295033916:main Q:Reg/w0 : errmsg.c: Called LogMsg, msg: program ''sudo' (pid 9275) exited with status 1
0384.295074123:main Q:Reg/w0 : operatingstate.c: osf: MSG program ''sudo' (pid 9275) exited with status 1: signaling new internal message via SIGTTOU: 'program ''sudo' (pid 9275) exited with status 1 [v8.2312.0]'
0384.295370296:main Q:Reg/w0 : errmsg.c: Called LogMsg, msg: file size limit cmd for file '/var/log/errorlog.txt' did no resolve situation
0384.295407136:main Q:Reg/w0 : operatingstate.c: osf: MSG file size limit cmd for file '/var/log/errorlog.txt' did no resolve situation
--- End code ---
So: it indeed seems to call the script, but execution is not really successful. Rsyslog even identifies that reducing filsize failed
Any ideas???
If I cannot get this to wrok I will divert to an alternative log cleaning method.
Maybe just do a quarterly cron to check filesizes and clean
patrikg:
Maybe when log rotate, it uses/calls to some library to compress that is not reached.
Check with ldd or even it's static so when configure and compiling you can enable or disable that feature.
Or even escape that space because it launches sudo without any args.
Or try just doing some debugging how that command being executed, and what environment it has.
Just add command id > /tmp/debug.log, to see what user executing.
If you also get that /tmp/debug.log file, if the command being executed with the args.
If that is not the case, you maybe can build a shell script to circumstance that the command is not being executed with any of the args. And then just add that script to your rsyslog conf.
Maybe it not using its correct systemcall, how to pass the args.
man 3 exec
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version