[ 
https://issues.apache.org/jira/browse/LOG4NET-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057612#comment-15057612
 ] 

Dominik Psenner commented on LOG4NET-496:
-----------------------------------------

I do not think that you have to grant permissions to the log directory as a 
mutex is requested operating system wide. The second process requesting the 
mutex throws an UnauthorizedAccessException because the mutex already exists 
and the process does not have the mutex privilege SYNCHRONIZE|MUTEX_MODIFY or 
MUTEX_ALL respectively. I'm not that familiar with cloud services, but maybe 
there's some magic switch or configuration option that allows you to configure 
this for your application?

Another option could be to try to create the mutex and if that fails with an 
UnauthorizedAccessException we could try to open the existing mutex. But this 
feels hacky and it would introduce a race condition if the mutex exists but is 
released by the first process before the second process can open it.

> RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
> ----------------------------------------------------------------------
>
>                 Key: LOG4NET-496
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-496
>             Project: Log4net
>          Issue Type: Bug
>    Affects Versions: 1.2.14
>            Reporter: Fabian Pachner
>
> We upgraded our Azure cloud service project from log4net 1.2.13 to 1.2.14 and 
> received the following exception when the web roles are starting up:
> {code}
> System.UnauthorizedAccessException: Access to the path 
> 'C__Resources_directory_9b9a1e064b78414281c81f861d0634b0.Role.Web.Frontend.DiagnosticStore_LogFiles_UI_UI_0'
>  is denied.
>    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>    at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>    at 
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
>  code, CleanupCode backoutCode, Object userData)
>    at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean 
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES 
> secAttrs)
>    at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, 
> Boolean& createdNew, MutexSecurity mutexSecurity)
>    at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, 
> Boolean& createdNew)
>    at log4net.Appender.RollingFileAppender.ActivateOptions()
>    at Base.Logging.AzureFileLogAppender.ActivateOptions() in 
> j:\Source\Commons\Logging\AzureFileLogAppender.cs:line 95
>    at 
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
>  appenderElement)
> {code}
> This affects the w3wp process of the web role. A consequence of this is that 
> file logging isn't working for that process. We didn't have that exception 
> with log4net 1.2.13 and recognized there was a change in 1.2.14 in 
> RollingFileAppender.ActivateOptions: A mutex is created there and that seems 
> to lead to the mentioned exception.
> Can you tell us whether it is likely that this issue was already fixed with 
> 1.2.15? And if so, when will this version be available via Nuget package? 
> Thank you!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to