point of recommendations for Windows Service

[alphaz18 1]

I've been running emby for many years and did the nssm thing last time around, but never stopped to read the implications eg no updating properly, and always got irritated that every once in a while if emby crashed it never came back.

I was reading on how to run emby as a service, and theres is documentation that uses NSSM with some specific settings.

and i realized, the recommendations is kind of super useless.
per the kb article it says to make sure it doesn't restart .. which is stupid since any crash or anything and the application won't restart..

you may as well just have a scheduled task, to start emby on boot because that's all the nssm is doing with the recommended settings...

Or if someone could enlighten me as to why it's any different?

Also, the kb says very important to do that otherwise the shutdown button won't work. It's a server.. it should never be shutdown. that button shouldn't even exist.

what is the use case to shutdown a server software from within the software itself? if anything the shutdown button should turn off the machine?

sorry for the rambling.. i just think that's a design flaw / bug that should be fixed.

 

Thanks

[Abobader 3464]

Hello alphaz18,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 42078]

Quote

what is the use case to shutdown a server software from within the software itself? if anything the shutdown button should turn off the machine?

A use case is you might want to stop the software to perform some kind of task and then start it back up again after that.

[alphaz18 1]

but in that case, you'll have to log into the server to manually start it up again anyway, so there would be no functional difference, since you need to log in anyway may as well stop the service from the os?

[Luke 42078]

7 minutes ago, alphaz18 said:

but in that case, you'll have to log into the server to manually start it up again anyway, so there would be no functional difference, since you need to log in anyway may as well stop the service from the os?

Right, it's useful for people who are not running a service, so that's why it's there. Additionally, even though you can stop it from windows services, not everyone knows that, and even if they did, it's still useful having it directly in the software.

[alphaz18 1]

 

4 minutes ago, Luke said:

Right, it's useful for people who are not running a service, so that's why it's there. Additionally, even though you can stop it from windows services, not everyone knows that, and even if they did, it's still useful having it directly in the software.

Thanks, I can accept that its useful in those cases ,

but you didn't address my main point which is that it is utterly pointless to have emby as a windows service via nssm configured per the recommendations because it literally is the same as having it as a scheduled task. the main benefit of a service is for failure recovery and restart.

Edited January 6, 2023 by alphaz18

[Luke 42078]

24 minutes ago, alphaz18 said:

 

Thanks, I can accept that its useful in those cases ,

but you didn't address my main point which is that it is utterly pointless to have emby as a windows service via nssm configured per the recommendations because it literally is the same as having it as a scheduled task. the main benefit of a service is for failure recovery and restart.

I don't think it's exactly the same, however it's been a few years since I've looked at this and without digging up all of the details again, this is just off the top of my head. I know that we researched all of the available options at the time and went with what we thought was best.

[alphaz18 1]

17 minutes ago, Luke said:

I don't think it's exactly the same, however it's been a few years since I've looked at this and without digging up all of the details again, this is just off the top of my head. I know that we researched all of the available options at the time and went with what we thought was best.

with windows task scheduler you can start applications without being logged in using whatever account as well,
So i feel like if we use nssm to disable auto restart.. then it doesn't really provide any benefit.. ?

I could very well be wrong, but from my like decades of IT servers experience, the primary purpose of having a windows service is to keep something running so that its accessible at all times.

Also given the fact that the docs mention you can't update when its a service, i think a better architecture would be to have a small

windows service wrapper app that has a small amount of logic in there that will handle a bit of extra logic needed to let emby update itself then restart the main emby.exe after completion. this lets you decouple the main emby.exe from the windows service component but still can handle updates automatically through ui. and it would allow it to handle restarting the service and keep it running all the time.

[Luke 42078]

Quote

i think a better architecture would be to have a small

windows service wrapper app that has a small amount of logic in there that will handle a bit of extra logic needed to let emby update itself then restart the main emby.exe after completion. this lets you decouple the main emby.exe from the windows service component but still can handle updates automatically through ui. and it would allow it to handle restarting the service and keep it running all the time.

Hi, yes this is the ideal. But until we're able to allocate developer time to windows services, nssm is the closest thing apart from the ability to self-restart and the fact that it has an ugly  name.

[Mnejing 23]

2 hours ago, alphaz18 said:

 

Thanks, I can accept that its useful in those cases ,

but you didn't address my main point which is that it is utterly pointless to have emby as a windows service via nssm configured per the recommendations because it literally is the same as having it as a scheduled task. the main benefit of a service is for failure recovery and restart.

Careful assuming that because it's pointless for you that it isn't pointless for someone else. Everyone has their own use-case. If installing as a service with nssm isn't for you, that's fine, but it does have value to others. And a scheduled task is full of it's own problems. That's kind of the nice thing, you can choose how to administer the server, if you so choose.

Edited January 6, 2023 by Mnejing

[alphaz18 1]

1 hour ago, Mnejing said:

Careful assuming that because it's pointless for you that it isn't pointless for someone else. Everyone has their own use-case. If installing as a service with nssm isn't for you, that's fine, but it does have value to others. And a scheduled task is full of it's own problems. That's kind of the nice thing, you can choose how to administer the server, if you so choose.

I disagree, its not that i'm saying its useless ""for me" i'm saying its useless in general. there is no valid use case to use nssm (with restart disabled per recommendations) over task scheduler, unless you can find me one. i'm happy to be proven wrong. but until then, I'll stick to my statement.

[alphaz18 1]

3 hours ago, Luke said:

Hi, yes this is the ideal. But until we're able to allocate developer time to windows services, nssm is the closest thing apart from the ability to self-restart and the fact that it has an ugly  name.

Cool thanks for that, that's a perfectly reasonable response

[pwhodges 2012]

I use nssm for a number of things, including Emby; I just find it the easiest way to set up any arbitrary service without having to think.  And of course I have it set to restart the service if it crashes (it never has)!

Paul

[alphaz18 1]

4 hours ago, pwhodges said:

I use nssm for a number of things, including Emby; I just find it the easiest way to set up any arbitrary service without having to think.  And of course I have it set to restart the service if it crashes (it never has)!

Paul

ya i mean, that's exactly it. its only useful if you have it set to restart if it crashes but you're going against the recommendations..

your emby has never crashed? i'm impressed.. i mean mine doesn't crash often. but i think once in a blue moon it will crash. and if you're say out of the house watching it on a tablet or phone or something, it makes it difficult to restart it.. but i mean overall its not a major gripe for me, more of an annoyance

 

[Mnejing 23]

8 hours ago, alphaz18 said:

I disagree, its not that i'm saying its useless ""for me" i'm saying its useless in general.

That's your prerogative.

I'm outright telling you that I prefer running it as a service with nssm, which is in direct opposition to your avowed statement.

[alphaz18 1]

34 minutes ago, Mnejing said:

That's your prerogative.

I'm outright telling you that I prefer running it as a service with nssm, which is in direct opposition to your avowed statement.

your statement is not at all in opposition to my statement. just because you like to do something doesn't make it useful.

you have not given me a single objective benefit of doing it other than "I like to do it" it's like saying when i drink water i will go and bring out two glasses and pour the water between the two glasses every time i take a sip. it provides no extra benefit, I can do it, because maybe i like to do it, but it is still not useful.

now what pwhodges mentioned above that he does, absolutely does bring benefit, he set it to automatically restart. which brings the very benefit of what windows services are DESIGNED to do, which is to restart when needed to keep the service up and running as much as possible. that's USEFUL. however he is going against the "recommendations" .

[Mnejing 23]

Understood, only your opinion is valid here. That you'd think a server service is best served by a scheduled task is about all that needs to be said.

I'll take my leave, as I'm not even entirely clear as to what you intended to accomplish with this post. Running Emby as service by means of nssm is simply one option available to people. If it doesn't work for you, then that's fine. It works just fine for other people, some of whom have even posted in this thread. There are literally a bunch of different ways run an Emby servers, that's the great thing about servers.

And yes, for the record, my statement is indirect opposition to what you said. You think it's a useless feature for everybody, that includes me, and I'm outright telling you I think it's a useful feature that I use.

Anyway, seriously, I'm not here to argue, and I'm not sure why I'm letting this bother me. Have a good one.

[alphaz18 1]

you did not specify why it's useful, not once.

The way it's recommended is to set it NOT to restart which absolutely does make it useless.

That you'd think a service is useful that a SERVER SERVICE does not restart says everything about what you understand about Windows services. There is absolutely no difference between a Non-restarting Windows service to a scheduled task. you have simply added the complexity of an additional piece of software that is essentially doing a scheduled task to start emby once on boot.

If you understood how windows services worked, you'd understand that removing auto-restart completely defeats the definition of a windows service.

my whole post was about wanting it to restart and be able to update as an improvement.

 

[rbjtech 5284]

The emby 'recommendations' are there to avoid support calls on upgrades, they are frankly wrong ..

I run emby as a service and have it set as a service should be ..

• No logon required (safer)
• Logon as a Dedicated service account 
• Restart on failure - bonus is if you do a shutdown in Emby (by mistake), it just restarts emby.  To shutdown - stop the service.
• Delayed Startup (to allow time for disk pooling/mounts etc)

ie - all the benefits of using a service over a desktop app.

For updates, a simple script to shutdown the service, install the latest, and re-start is quick and easy.  Infact for a 'Production' system you do not want to auto upgrade to a new release anyway - so that's a bonus !

Edited January 7, 2023 by rbjtech

[alphaz18 1]

7 minutes ago, rbjtech said:

The emby 'recommendations' are there to avoid support calls on upgrades, they are frankly wrong ..

I run emby as a service and have it set as a service should be ..

• No logon required (safer)
• Logon as a Dedicated service account 
• Restart on failure - bonus is if you do a shutdown in Emby (by mistake), it just restarts emby.  To shutdown - stop the service.
• Delayed Startup (to allow time for disk pooling/mounts etc)

ie - all the benefits of using a service over a desktop app.

For updates, a simple script to shutdown the service, install the latest, and re-start is quick and easy.  Infact for a 'Production' system you do not want to auto upgrade to a new release anyway - so that's a bonus !

rgjtech, Thanks for that, I'm in total agreement, the recommendations are functionally wrong. as they defeat the purpose of a service.

I'm glad to see someone follow best practices to use a dedicated service account  

Also for the updates, That's a very good point, in a real production environment you probably wouldn't want auto update, but as a home environment I don't think it would be bad to have it update by itself, people are lazy, and want the latest features  
Thanks, maybe i'll just write up a quick update script in PS, and have it periodically run using task scheduler, would you happen to know what technically is preventing the app from self updating when it's a service? is it just timing?

 

[rbjtech 5284]

10 minutes ago, alphaz18 said:

Thanks, maybe i'll just write up a quick update script in PS, and have it periodically run using task scheduler, would you happen to know what technically is preventing the app from self updating when it's a service? is it just timing?

 

have a dig on the forum - I think there are already some PS examples that also do a usage query using the emby API - ie you don't wanna shut it down if it's in use...

The live update process even as an app is a little, lets be kind and call it 'quirky' - I suspect it's related to locked db's but that's just a hunch.

For updates, I generally just shutdown the service and extract the release over the top.  I don't generally run as an App, let it do the update and then shutdown the App, then restart as a service but that's an alternative way.

 

[pwhodges 2012]

In defence of the recommendation not to configure automatic restarts, I picture the support problem when someone has a database or other problem that leads to a crash - a loop of restarting and crashing could be messy, and maybe the person who wrote the procedure had once had to deal with it remotely...

Paul

[alphaz18 1]

2 hours ago, pwhodges said:

In defence of the recommendation not to configure automatic restarts, I picture the support problem when someone has a database or other problem that leads to a crash - a loop of restarting and crashing could be messy, and maybe the person who wrote the procedure had once had to deal with it remotely...

Paul

That's a fair point from a support perspective, at the same time people who would be turning it into a service would likely be knowledgeable enough to go to services and stop it, 

I don't know if I'm the only one, but I've had emby crash on many occasions where it's fine if you just run it again, I never cared enough to do a root cause since it happens seldomly, and restarts just fine, but I'd imagine if the db was corrupted enough to prevent start, the user has bigger problems on their system

Also typically in Windows services you could configure failure count, eg to restart a few times on failure and after say 3 times, stop trying, 

[Happy2Play 9780]

Stopping a Service for Emby will not gracefully shut down Emby so you have potential issue with Locked database or ever corrupting the database.  Recovering from an open database can be problematic.

[alphaz18 1]

21 minutes ago, Happy2Play said:

Stopping a Service for Emby will not gracefully shut down Emby so you have potential issue with Locked database or ever corrupting the database.  Recovering from an open database can be problematic.

That behaviour would be pretty specific due to the use of nssm. In a proper Windows service, if you shutdown a service, it will call the internal shutdown method of the application and presumably handle ensuring database connections closed. You've basically just given another reason why it's not a great solution run it through nssm like that.