MonitorWare Knowledge Base

by **paf** » Tue Jan 27, 2009 5:03 pm

Hello!

I really need the ability to reload the configuration files via the HANGUP signal, but it doesn't seem to be working.
I'm running rsyslogd 4.1.3, and attempt to run kill -HUP <pid> (both under root privileges and under to syslog user). It doesn't seem to work, and I've tried it without having the $HUPisRestart, and both by trying to put in the configuration file "$HUPisRestart on" and "$HUPisRestart off" (just in case I was going mad).

I will also point out that when I kill and then re-run the daemon, it works perfectly with the updated configuration.

Is there a reason why this might be happening?

Learn more about rsyslog professional services.

Custom written rsyslog.conf?
Maintenance Contract?
Installation support?

by **rgerhards** » Tue Jan 27, 2009 5:05 pm

Please provide a debug log with $HUPIsRestart on. It should include the startup, and the HUP. Details:

http://www.rsyslog.com/doc-troubleshoot.html

by **paf** » Wed Jan 28, 2009 9:02 am

You're right, sorry.

Here are the interesting bits from the log, ran as you explained. If the rest is needed, you'll have to explain to me why can't I attach it...

9027.667821197:main thread: Writing pidfile /var/run/rsyslogd.pid.
9027.668012387:main thread: rsyslog 4.1.3 - called init()
9027.668030928:main thread: Unloading non-static modules.
9027.668047294:main thread: module lmnet NOT unloaded because it still has a refcount of 3
9027.668062299:main thread: Clearing templates.
9027.668103700:main thread: cfline: '$PrivDropToUser syslog'
9027.668378669:main thread: uid 101 obtained for user 'syslog'
9027.668396987:main thread: cfline: '$HUPisRestart on'
9027.668414288:main thread: cfline: '$ModLoad imudp # provides UDP syslog reception'
9027.668435038:main thread: Requested to load module 'imudp'
9027.668453094:main thread: loading module '/usr/local/lib/rsyslog/imudp.so'
9027.668518494:main thread: source file imudp.c requested reference for module 'lmnet', reference count now 4
9027.668543632:main thread: module of type 0 being loaded.
9027.668561301:main thread: cfline: '$ModLoad imtcp # provides TCP syslog reception and GSS-API (if compiled to support it)'
9027.668578222:main thread: Requested to load module 'imtcp'
9027.668594277:main thread: loading module '/usr/local/lib/rsyslog/imtcp.so'
9027.668648755:main thread: source file imtcp.c requested reference for module 'lmnet', reference count now 5
.
.
.
9027.694032451:main queue:Reg/w0: main queue:Reg/w0: worker IDLE, waiting for work.
9037.921017509:imuxsock.c: Message from UNIX socket: #3
9037.921061887:imuxsock.c: logmsg: flags 4, pri 85, from '127', msg Jan 28 09:50:37 sudo: user : TTY=pts/3 ; PWD=/etc/rsyslog.d ; USER=root ; COMMAND=/bin/kill -HUP 20786
9037.921075867:imuxsock.c: Message has legacy syslog format.
9037.921095349:imuxsock.c: main queue: entry added, size now 1 entries
9037.921113124:imuxsock.c: wtpAdviseMaxWorkers signals busy
9037.921129786:imuxsock.c: main queue: EnqueueMsg advised worker start
9037.921194936:imuxsock.c: --------imuxsock calling select, active file descriptors (max 3): 3
9037.921222738:main queue:Reg/w0: main queue: entry deleted, state 0, size now 0 entries

BTW, on the stdout it actually says

rsyslogd: [origin software="rsyslogd" swVersion="4.1.3" x-pid="20786" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.

by **rgerhards** » Wed Jan 28, 2009 9:07 am

ahhh... OK, I see the cause. You drop privileges. I think this is documented (at least should so): if you drop privileges, you can not do a full restart. The reason is that you would need to aquire root privileges to do so. That you can't, because you've dropped them. We do not want to be able that an attacker may reclaim privileges, so we drop them without the ability to reclaim them (which I think would really, really circumvent the protection you intend to gain).

So in short: if you drop privileges, a full restart is not available. You need to pick either one of these options, both together are impossible.

I hope this clarifies.
Rainer

by **paf** » Wed Jan 28, 2009 9:36 am

I don't think it was documented.
Anyway, it's extremely problematic that you cannot restart it from its own privileges, and it also makes no sense - the sheer fact that it's running under non-root privileges doesn't necessarily mean it can't re-read configuration files, re-open output channels and re-run.
Moreover, the original standard syslogd can be restarted using HUP even when not running with root privileges.

I would much appreciate it if you could explain the reason for this decision.

For the time being, I'll remove the $PrivDropToUser command, which kind of misses the whole "security" aspect of it all.

Thanks for your help!

by **rgerhards** » Wed Jan 28, 2009 9:39 am

just one answer: how do you bind to port 514 if non root? Please explain in detail how sysklogd can do that, then I can either implement it that way or tell you (much more probably

) where the security weakness is.

by **rgerhards** » Wed Jan 28, 2009 9:40 am

well, I think I can answer the question myself: sysklogd can not dynamically change if it is listening or not. So no issue there - because it does not have the functionality.

by **rgerhards** » Wed Jan 28, 2009 9:41 am

and, as another side-note, why can't you simply restart the syslogd after a config change? just use restart wherever you used to say kill -hup... I don't see any issue with that approach. Is there one?

by **paf** » Wed Jan 28, 2009 1:47 pm

It is a matter of elegance - sending a signal is much more API friendly than running start-stop-daemon (or whatever).

I did not understand your prior comment - I was running rsyslog as the syslog user (which also runs the original sysklogd), and it binds the 514 port perfectly. It seems to make sense to me, though I might be mistaken.

by **rgerhards** » Wed Jan 28, 2009 1:49 pm

It can bind to port 514 because it drops privileges after it has bound to the port.

by **paf** » Wed Jan 28, 2009 2:16 pm

So, if I understand what you're saying, when getting the HUP it can't regain its root privileges, and therefor can't reopen the port.
Can't it be kept open through the reload?

by **rgerhards** » Wed Jan 28, 2009 2:21 pm

yes, your understanding is correct. And, no, the port can not be kept open, at least not with the current design. The reason is that imudp may no longer be present in the new config. You can correctly argue that if a delta of the config is taken, and the port is not changed, there is no problem. This is right. But this is not currently supported and a major effort to implement. Even then, you have to answer the question what to do if imudp was not present in the config before the hup but is after - in that case, the port can not be bound. Another of these interesting questions is what to do if the new config drops privileges to a different user - this is (usually) no longer possible, once you have dropped privileges to another user. So there are a couple of very good questions that need to be answered.

There always remain situations where a config reload is impossible after privileges have been dropped. What than? Ignore the HUP? Terminate the syslogd? Either is a bad idea. So it is probably better to provide a working and consistent solution and not permit restart via a HUP - at the cost of the slight inconvenience that a restart must be done like a restart is usually done, by restarting the service in question.

by **paf** » Wed Jan 28, 2009 2:39 pm

Understood.
Thanks for your continuous help and attention.

by **rgerhards** » Wed Jan 28, 2009 2:40 pm

my pleasure. Restarting the daemon is actually much harder than it looks on quick view. And I obviously need to check the docs...

MonitorWare Knowledge Base

$HUPisRestart Doesn't Seem to Work

$HUPisRestart Doesn't Seem to Work

Professional Services Information

Learn more about rsyslog professional services.

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Re: $HUPisRestart Doesn't Seem to Work

Google Ads

Who is online