Hi David, You understood my predicament well.
I looked a bit closer at what you mentioned for approach #1. The Light-weight processes/threads for Rsyslogd can be found for the process under /proc/<rsyslog pid>/task/<lwp pid>/ . Looking at their 'stat' file, I see that they actually named as their module name (like: "in:imfile"). So theoretically, I could go through this tree programmatically, and find the right module to send a SIGSTOP to. Barring that no broad lock is held by the system, input modules should still process while I stop this output module, putting them in the queue of the relevant output modules. Then I'd send a SIGHUP to the main process for the file handles to be released, and a SIGCONT to the module for things to continue. Is this as thin ice as it sounds like? How bad would the temporary stopping of Rsyslog be, in comparison? Is it always the case that messages sent during this time will be lost? Unfortunately, using v8 is not an option, since it's not yet supported in the distro I'm using. Regards, Anders -----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of David Lang Sent: den 9 april 2014 18:37 To: rsyslog-users Subject: Re: [rsyslog] Fwd: Handling of SIGTSTP and SIGSTOP signals On Wed, 9 Apr 2014, Anders Olsson wrote: > Hi, > > > > I'm wondering about how and if at all RSyslog handles voluntary stop > signals: TSTP. I have not been able to find any concrete information > on this, but maybe my google-fu is weak. > > > If there is no voluntary stop handling, how about mandatory stop signals: > STOP? How will the program behave? My expectation is that it will not > handle any incoming messages, and in the case of UDP they will be lost. > > > > I'm running RSylog 7.4.4 on x86_64 embedded Linux. > > > The reason I'm wondering this is because I have the need to move the > location rsyslog writes to during the boot phase. RSylog is started > early in the boot phase, when this particular system has no persistent > storage area mounted - the logs go into ramdisk. Later in the boot > phase network storage is attached. At this point, I would like to be > able the halt RSyslog from writing to file, so that the logs on > ramdisk can be moved, and then continue to be appended at the new > location. Just sending a HUP signal to rsyslog could cause out of > order or lost logs, depending on the order of doing move compared HUPing. move vs HUP should always be that you move the file then send the HUP, but only on the same filesystem. but if I understand what you are doing, you are trying to do mv /ramdisk/dir/file /ramdisk/dir2/file ln -s /realdisk/dir /ramdisk/dir mv /ramdisk/dir2/file /ramdisk/dir/file The problem is that when you move the file from one filesystem to another while something is writing to it, you will always have a race condition between writing to the file and the copy of the file. In addition, since rsyslog only creates a file as-needed, it could create a file as you are doing the link. Thinking about this in 'blue sky' view, I see two approaches to deal with this 1. pause rsyslog output while you do the shuffling 2. tell rsyslog to move it's output from one place to another instead of switching storage under it. It sounds like you are looking at #1. I'm not sure exactly what rsyslog does (especially since there are multiple threads, you may be able to signal individual threads, but you can end up blocking if you pause a thread that holds a lock) for #2, you could use global variables in v8 and dynamic filename templates to have rsyslog start logging to one place, and then change to log somewhere else. The problem is what to do with the logs from the ramdisk, and I think my answer to that is treat them like rotated logs David Lang > > Any ideas on this would be much appreciated. > > > Best Regards > > Anders > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
