Command with arguments in newsyslog configuration

J

jmpalacios

Hi everyone,

I'm trying to configure log rotation via newsyslog for ZoneMinder. Problem is that, according to ZoneMinder's recommendation, I need to execute a command upon log rotation, rather than sending a PID a signal, and that command takes an argument.

The configuration I have so far looks like this:

Code: 
/var/log/zm/*.log                www:www     640 7 * $D0 GJR /usr/local/bin/zmpkg.pl logrot

But a syntax test reveals that newsyslog rejects that:

Code: 
-> newsyslog -nvv
(…)
newsyslog: illegal signal in config file:
/var/log/zm/*.log                www:www     640 7 * $D0 GJR /usr/local/bin/zmpkg.pl logrot
(…)

If I remove the "logrot" argument, even it it's by inserting a # comment right before it, then the syntax check passes, but that'd be an invalid invocation of the zmpkg.pl command, as the argument is required.

Quoting the command as either "/usr/local/bin/zmpkg.pl logrot" or '/usr/local/bin/zmpkg.pl logrot' don't help, with newsyslog still producing the "illegal signal" error in either case.

So, in short, is there a way to configure newsyslog log rotation to execute a command that takes arguments?

Thank you!
 
Doesn't look like it from reading the man page. I just checked to see what I did:

Code: 
% cat /usr/local/etc/newsyslog.conf.d/zm.conf 
# logfilename       [owner:group]  mode  count  size  when   flags  [/pid_file]                     [sig_num]
/var/log/zm/*.log   www:www        644   3      *     $M1D0  GR     /usr/local/bin/kj-zm-logrotate

% cat /usr/local/bin/kj-zm-logrotate
#!/bin/sh
/usr/local/bin/zmpkg.pl logrot
 
Hi kjeacle!
kjeacle said:
Doesn't look like it from reading the man page. I just checked to see what I did:

Code: 
% cat /usr/local/etc/newsyslog.conf.d/zm.conf
# logfilename       [owner:group]  mode  count  size  when   flags  [/pid_file]                     [sig_num]
/var/log/zm/*.log   www:www        644   3      *     $M1D0  GR     /usr/local/bin/kj-zm-logrotate

% cat /usr/local/bin/kj-zm-logrotate
#!/bin/sh
/usr/local/bin/zmpkg.pl logrot
Click to expand...
Yeah, I figured I could always absorb the necessary command invocation into a script, which I've done before when the action I need execute upon log rotation is more complex than just invoking a single command and passing arguments/flags.

But, for a case as simple as this one, is quite a surprising limitation not being able to do it right in the configuration file!
 
Anyone passing by this thread have ideas on how to solve this newsyslog problem I'm facing without resorting to a script that would absorb in a single invocation the command I need to execute and its argument(s)/flag(s)?

Thank you!
 
Just had a look at newsyslog.c and it uses isspace() to delimit fields so there is no support for passing arguments. When the command is run, it actually passes the optional signal number field as an argument.
Code: 
asprintf(&tmp, "%s %d", swork->sw_fname, swork->sw_signum);
...
kres = system(tmp);
 
kjeacle said:
Just had a look at newsyslog.c and it uses isspace() to delimit fields so there is no support for passing arguments. When the command is run, it actually passes the optional signal number field as an argument.
Code: 
asprintf(&tmp, "%s %d", swork->sw_fname, swork->sw_signum);
...
kres = system(tmp);
Click to expand...
Thanks for the hint!

I'm looking at https://cgit.freebsd.org/src/tree/usr.sbin/newsyslog/newsyslog.c#n2094, which I believe is what you're referencing, and how swork->sw_signum, i.e. the signal number, is passed as the value of the %d parameter of the string buffer that then gets executed via system(3).

But, if I'm understanding the newsyslog.conf(5) man page correctly, when the R flag is present, the specified command is run "instead of trying to send signal to a process id stored in the file.". So, in that case, why would the most-probably-empty-signal-argument be of any use to the executed command? Doesn't this sound to you like a ripe opportunity for a feature enhancement? "When the R flag is present, any remaining fields are passed as arguments to the command to be executed".
 
Not clear why the signal argument is passed. Worth noting that this feature came from the "FreeBSD hacking lounge at BSDCan" so maybe there was a discussion about a potential use case but it was never documented. Passing the remaining fields as arguments does seem like a reasonable suggestion.
 
Gonna try to obtain an answer to that right from the horse's mouth ;) Let me know if you'd like to join the conversation.
 
You must log in or register to reply here.
Back
Top