Empty PID file?

[soniCron 5]

Trying to monitor the emby-server process using Monit on Ubuntu 15.04 since Emby crashes several times a day and the /var/run/emby-server.pid is being created but is 0 bytes, so it can't monitor the process that way.

 

I assume this is a bug?

 

Obviously there are other ways to monitor the process, but this is the "appropriate" way, so I hope it's just been overlooked?

 

Thanks!

[hurricanehrndz 149]

PID file shouldn't be empty. PS Emby shouldn't crash. My instance has been up for 20 day right now. Please look into mono and kernel issues.

[soniCron 5]

PID is empty no matter what I do, and I've tried several re-installs to no avail. (Using install directions on main website.) No biggie, just thought I'd mention it.

 

However, the crashing, I've found the cause and resolved it: File system monitoring was causing the crash. For what reason, I don't know. It worked most of the time, but the server would still crash a couple times a day. Once I realized what was happening when it crashed, I turned off real-time monitoring and it hasn't crashed in a day and a half so far!

 

FWIW, I have FAT32 and EXT4 with media, I have no idea which partition (or both) were responsible. Kernel is 3.16.0. Error was not very helpful:

Object reference not set to an instance of an object
System.NullReferenceException
  at System.IO.InotifyWatcher.ProcessEvents (System.Byte[] buffer, Int32 length) [0x00000] in <filename unknown>:0 
  at System.IO.InotifyWatcher.Monitor () [0x00000] in <filename unknown>:0 
  at System.Threading.Thread.StartInternal () [0x00000] in <filename unknown>:0 

No info preceding the error indicated what, exactly, was going on when the crashes happened.

 

(I also have several crashes because of the Trakt plugin during 500 errors from the Trakt servers, but that's obviously not anything to do with the Linux build! So I'm not knocking your builds or anything! )

[hurricanehrndz 149]

Interesting, please look into the init script. There is a pgrep command that should be populating the pid. If for whatever reason when you run the command as root it doesn't return anything, then please try adjusting the command and report back. I will be more than happy to adjust what is being packaged, but the pgrep command is pretty successful in most cases.

[soniCron 5]

I waited a few days to test because I was taking stock of a different bug (which I'll post in a separate thread) which takes a few days to manifest.

 

However, I just checked this and it looks like the issue is resolved in the current version! So, no PID problems, now!

 

Thanks for your help!

[deepseth 10]

Apologies if I'm going wrong here, I don't have access to SSH at this time to look at the init scripts involved, but why not use $! to return the PID of the last run process after the command to actually start emby-server, rather than pgrepping?

 

/path/to/start/emby-server && pid=$!

echo $pid > /var/run/emby.pid 

 

or something to that effect?

[hurricanehrndz 149]

Apologies if I'm going wrong here, I don't have access to SSH at this time to look at the init scripts involved, but why not use $! to return the PID of the last run process after the command to actually start emby-server, rather than pgrepping?

 

/path/to/start/emby-server && pid=$!

echo $pid > /var/run/emby.pid 

 

or something to that effect?

It will not get the right pid if there is forking. I'm not sure how exactly emby works but in my initial developments when I did as you suggested the pid return was almost always wrong.