Oxide logs randomly stops working with exception
Topkek
Something very wrong is happening after the horse update:
IOException: Sharing violation on path C:\rust_ded_dir\rust\server\inst\oxide\logs\oxide_2019-06-12.txt
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0019e] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean isAsync, System.Boolean anonymous) [0x00000] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access) [0x00000] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess)
  at Oxide.Core.Logging.RotatingFileLogger.BeginBatchProcess () [0x0000c] in <4452f821def6406d834e4149849fe7ea>:0 
  at Oxide.Core.Logging.ThreadedLogger.Worker () [0x0002f] in <4452f821def6406d834e4149849fe7ea>:0 
  at System.Threading.ThreadHelper.ThreadStart_Context (System.Object state) [0x00014] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00071] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x0002b] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
  at System.Threading.ThreadHelper.ThreadStart () [0x00008] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
UnityEngine.UnhandledExceptionHandler:<RegisterUECatcher>m__0(Object, UnhandledExceptionEventArgs)​

Its happened 2 times already on a single server, since horse update. After this exception, oxide log file isn't working. Oxide starts logging again, when the day ends (and there is new logfile in a rotation)
Wulf
uMod Admin
"Sharing violation on path" means that something was trying to use and lock that file while it was trying to be written to. Our logging handling has not changed though, and this would not be triggered by a game update.
Topkek
Original Poster
In response to Wulf (View post):
"Sharing violation on path" means that something was trying to use and lock that file while it was t...
Well, there wasn't any issues in latest 15 months. Just checked, every single log file has last modification time at 23:58-23:59. And i didn't really changed anything lately. The only way i interfere with logs is opening them via WinSCP, and i never pressing "save" button. Can it be caused by upgrade of the Unity to 2019.1, or oxide logging implementation is completely written by yourself? I also had one issue, that -logfile didn't created any logs, until i switched from relative to absolute path, and then it worked fine.

Unity logging has been changed in 2019.1, as you can see from the patchnote:
Editor: Added a fix for consistent logfile option handling for all desktop platforms, the Editor, and the Player. This improves the handling of edge cases and scenarios with logfile parameter. (900754, 960012, 1068907)​
And also some other changes, related to logging: https://unity3d.com/ru/unity/whats-new/2019.1.0
Wulf
uMod Admin
In response to Topkek (View post):
Well, there wasn't any issues in latest 15 months. Just checked, every single log file has last modi...
Unity's logging isn't related to our logging. Opening and viewing a log while it is trying to write cna cause this issue depending on what opens it.
Topkek
Original Poster
In response to Wulf (View post):
Unity's logging isn't related to our logging. Opening and viewing a log while it is trying to write...
Whats the safiest way to read the logs then? Or maybe can you catch the unsuccessful attempt to write log instead of stopping logging until 00:00 at all?
Wulf
uMod Admin
In response to Topkek (View post):
Whats the safiest way to read the logs then? Or maybe can you catch the unsuccessful attempt to writ...
I would download them and review them. The log handling does need some improvements I'm sure, but Oxide builds won't be receiving those, only uMod once it is available.
Topkek
Original Poster
In response to Wulf (View post):
I would download them and review them. The log handling does need some improvements I'm sure, but Ox...
Doesn't WinSCP is just downloading them? Ofcourse if you press save, it will then upload it back.

Will wait for umod, thanks, and also i hoppe, that this issue will be fixed too, at least there: https://umod.org/community/logger/259-calling-onservercommand-on-logger-took-xms?page=1#post-5
Wulf
uMod Admin
Yes, but saving them or uploading that file while the server is trying to save to it would be what causes it. I would not suggest saving over it.
Topkek
Original Poster
Okay, let's suppose, i just missclicked it, but iirc i didn't.