You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2021/06/09 11:01:00 UTC
[jira] [Work logged] (LOG4NET-587) Mutex ~ Access to the path is
denied in log4net.Appender.RollingFileAppender.ActivateOptions()
[ https://issues.apache.org/jira/browse/LOG4NET-587?focusedWorklogId=609082&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-609082 ]
ASF GitHub Bot logged work on LOG4NET-587:
------------------------------------------
Author: ASF GitHub Bot
Created on: 09/Jun/21 11:00
Start Date: 09/Jun/21 11:00
Worklog Time Spent: 10m
Work Description: markdemich commented on pull request #48:
URL: https://github.com/apache/logging-log4net/pull/48#issuecomment-857599126
Is there a reason this is not merged? I'm having this issue. I have multiple development app_pools in IIS that are attempting to write to the same log file and creating the same mutex. What's odd is this used to work, but now it's not and I can't figure out what changed. I wonder if newer versions of the .Net Framework or some windows security update broke this. It's been a long time since I updated log4net and I'm pretty sure this was working after that so I don't think it was an update to log4net. It seems the original mutex code was added in 2015. We would have notice this issue way before now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 609082)
Time Spent: 3h 20m (was: 3h 10m)
> Mutex ~ Access to the path is denied in log4net.Appender.RollingFileAppender.ActivateOptions()
> ----------------------------------------------------------------------------------------------
>
> Key: LOG4NET-587
> URL: https://issues.apache.org/jira/browse/LOG4NET-587
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.0.8
> Environment: Windows Server 2012 R2
> Reporter: Kira Resari
> Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> I have recently updated my log4net version from a really old Version (1.2.13) to the newest version, but ever since then, a component of my apache website service throws the following error message:
> {code:java}
> 2018-01-15 06:19:35,933 DEBUG - Exception-Message: Access to the path 'C__Rafina_LeBu_logs_NFDDL2.log' is denied.
> 2018-01-15 06:19:35,933 DEBUG - Exception-StackTrace: 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)
> at log4net.Appender.RollingFileAppender.ActivateOptions()
> at NFCIn.Logging.InL4NLogFac.LogImp..ctor(String name)
> at NFCIn.Logging.InL4NLogFac.CrLog(ILoggerRepository repository, String name)
> at log4net.Repository.Hierarchy.Hierarchy.GetLogger(String name, ILoggerFactory factory)
> at log4net.Repository.Hierarchy.Hierarchy.GetLogger(String name)
> at log4net.Core.LoggerManager.GetLogger(Assembly repositoryAssembly, String name)
> at log4net.LogManager.GetLogger(String name)
> at NFCIn.Log.L4NFac.b(LogName id)
> at NFDDL.DDo.probeDL2(DateTime dateStart, DateTime dateEnd, String headStatus, String transmissionStatus, String supplier, String documenttype, String documentsubtype, Int32 processed, String clientId, String documentUser)
> at NFIISWServ.Serv.pr(String base64request){code}
> Since the crux of the problem seems to be happening inside a log4net function call, I figured I'd post this here. Or is there already a workaround for this?
> By the way, this is the rollingAppender we're using:
>
> {code:java}
> var rollingAppender = new RollingFileAppender
> {
> File = logFileName,
> AppendToFile = true,
> Encoding = Encoding.UTF8,
> RollingStyle = RollingFileAppender.RollingMode.Size,
> MaxSizeRollBackups = 0,
> MaxFileSize = logSettings.MaxFileSize,
> StaticLogFileName = true,
> LockingModel = new FileAppender.MinimalLock(),
> Layout =
> new PatternLayout(
> logSettings.Pattern),
> Threshold = this.NfLogLevelToInternalLogLevel(logSettings.LogLevel)
> };
> rollingAppender.ActivateOptions();{code}
>
> I have already tried changing the value of LockingModel to InterProcessLock or commenting out that line. However, both approaches have only escalated the problem.
> On the other hand, that way I was able to confirm that this particular problem only happens on one specific page of our web portal, and that the log4net logger works just fine in other sections. Here is a comparison of the last diverging call between a working and a not working path:
> Working:
> {code:java}
> Dim log As ILogger = loggingFactory.build(LogName.NFDDL).open("Document.Parse"){code}
> Not working:
> {code:java}
> Dim log As ILogger = loggingFactory.build(LogName.NFDDL).open("DocumentDao.probeDocumentList2"){code}
> The value inside (open) is merely a log entry that should be written into the log, so I don't think that could be it.
> —
> UPDATE:
> By now, I've managed to escalate the error. It no happens on all sorts of pages of the portal even with previously working function calls, even though after all my experimentation on the issue I rolled all my changes back to the version I had this morning using git where the now additionally affected pages were still working. My assumption is that somewhere during my experimentation log4net mutex-locked some files and never released that lock. Can someone please help me with this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)