[pulseaudio-discuss] Logging startup of the first instance...

[rong deng]

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>