On Mon, Apr 14, 2014 at 9:13 PM, David Lang <[email protected]> wrote: > On Mon, 14 Apr 2014, Anders Olsson wrote: > > 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? >> > > not quite, but close. you do have the ability to name the actions and > rulesets (and their queues), so it's a little better than it sounds like. > > But there is a race condition because these threads do hold locks that > will block input threads. > > I also don't think that the HUP will be able to take effect while the > output threads are stopped. I believe that the signal will be delivered, > just not acted on until they are running again. > > > 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? >> > > Well, even with UDP, the OS will buffer some data, how much depends on > your OS settings. > > We really need Rainer to speak up about this.
Quite frankly, I haven't played with this nor put any thought into it. So I guess it boils down to testing... Rainer > > > Unfortunately, using v8 is not an option, since it's not yet supported in >> the distro I'm using. >> > > well, keep in mind that 7.4 isn't supported here because it's so old. So > you need to decide who you want support from and pick your version > accordingly ;-) > > only half kidding, if you are running an old version because it's what > your OS supports, you should be asking your OS support people for help. > > We try to help, but for an issue like this that is likely to involve real > low-level details, there's a limit to how much digging through old code we > will do, and if we find any issues, the fix will go into the current > version, there won't be an update to the old version. > > That said, you aren't on an ancient version, only two revs back from > current (we seem to finally be past getting a lot of requests for help for > 3.x versions, but we still get a lot fo 5.x), so it's not that bad. > > David Lang > > > 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. >> >> _______________________________________________ > 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.
