Hi David, Sorry for the top posting, I've added the O_EXCL flag and please review again. Thanks! 2012/6/28 rong deng <dzrongg at gmail.com>: > 2012/6/28 David Henningsson <david.henningsson at canonical.com>: >> On 06/28/2012 09:41 AM, rong deng wrote: >>> >>> Hi David, >>> >>> I've come up with an idea to accommodate this situation, tell me if >>> it's useful for you or there's a better solution. :) >> >> >> I think this solution (to go with .1, .2 etc prefix) is good enough for me. >> A question about the implementation though - is it racy? I'm not completely >> sure if two clients which in parallel try to spawn the server, end up >> choosing the same file name. > > Hi David, > > I'm afraid that the current implementation suffer the same race issue. > because the second server would just ignore the current existing file > and would be happy to create its own. It should be fixed. > >> >> Would opening with O_EXCL work as a test instead, perhaps? > > Yes, adding O_EXCL to open()'s flags would help in this situation. > >> >> >>> >>> So I've added a new syntax when we specified the file log target. The >>> original one is file:<PATH>, now it's newfile:<PATH>. ?This syntax >>> would: >>> 1. check if PATH file exists or not, if it doesn't exist, then >>> everything is OK, we're not overriding anything, we do the original >>> code route. >>> 2. now unfortunately this file exists, then we try PATH.1, PATH.2, >>> PATH.3 .... until we find a non-existent file, let's say it's PATH.5, >>> so we create the PATH.5 as our log file target. >>> >>> Any comments are welcome. >>> >>> The patch is attached. >>> >>> 2012/6/11 David Henningsson <david.henningsson at canonical.com>: >>>> >>>> On 06/11/2012 02:35 AM, rong deng wrote: >>>>> >>>>> >>>>> 2012/6/4 David Henningsson<david.henningsson at canonical.com>: >>>>>> >>>>>> >>>>>> Sometimes I have users who complain about some problem, but after a >>>>>> "pulseaudio -k" the problem is gone. Therefore asking them to restart >>>>>> pulseaudio with -vvvv switch will not give any information about the >>>>>> error. >>>>>> >>>>>> ?* I could log to syslog (the default), but once I enable debug level >>>>>> log, >>>>>> the syslog daemon can start to ratelimit, especially during the startup >>>>>> phase of pulseaudio. >>>>>> >>>>>> ?* I could log to file, but then that file would quickly get >>>>>> overwritten, >>>>>> as >>>>>> soon as pulseaudio restarts. >>>>>> >>>>>> Is there a trick I'm missing here? Or would it be possible to add some >>>>>> kind >>>>>> of expansion to the log file name to make the files unique? >>>>> >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> I'm doing the GSoC to enhance the logging functionality in pulseaudio, >>>>> I could take a look at this issue and try to improve it a little bit. >>>>> :) >>>> >>>> >>>> >>>> Yes, I was actually thinking the same :-) Thanks! >>>> >>>> Not sure how to do it in the best way though. I'm figuring that at least >>>> a >>>> timestamp and pid should be possible to insert into the log file name in >>>> a >>>> configurable way. >>>> Also we probably don't want to reinvent the wheel but use the expansion >>>> mechanisms provided by ...something around us, or some library we're >>>> already >>>> depending on, if we can find anything of use? >>>> Maybe someone else knows more on the topic. >>>> >>>> >>>> -- >>>> David Henningsson, Canonical Ltd. >>>> https://launchpad.net/~diwic >> >> >> >> >> -- >> David Henningsson, Canonical Ltd. >> https://launchpad.net/~diwic >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-a-new-log-target-that-enables-to-create-new-log-.patch Type: application/octet-stream Size: 4102 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20120629/02010be9/attachment-0001.obj>
