Replace supervisord with systemd #2387

@DanSheps commented on GitHub (Feb 15, 2019):

I think a better approach, would be to include a "contrib" directory and instead use envirovars to control certain settings in the unit file. Less overhead and less chance for a mistake.

Would streamline the install process too.

@DanSheps commented on GitHub (Feb 15, 2019): I think a better approach, would be to include a "contrib" directory and instead use envirovars to control certain settings in the unit file. Less overhead and less chance for a mistake. Would streamline the install process too.

adam commented

@candlerb commented on GitHub (Feb 15, 2019):

I am only proposing a simple swapout of supervisord config file with systemd config file.

@DanSheps: sorry I don't understand what you're saying. What exactly would you put in the "contrib" directory? What environment variables would "control certain settings", and how would the user be expected to set them?

@candlerb commented on GitHub (Feb 15, 2019): I am only proposing a simple swapout of supervisord config file with systemd config file. @DanSheps: sorry I don't understand what you're saying. What exactly would you put in the "contrib" directory? What environment variables would "control certain settings", and how would the user be expected to set them?

adam commented

@DanSheps commented on GitHub (Feb 15, 2019):

contrib would have:

contrib/netbox@.service
contrib/netbox.env

In the netbox.env, you have:

#WorkingDir='/usr/local/netbox/'
#NBUser='www-data'
#NBGroup='www-data'
#PidPath='/var/run/netbox.pid'
#Bind='127.0.0.1:8001'
#Workers=3
#Timeout=120
#Log='/usr/local/netbox/netbox.log'

If @jeremystretch is willing, I can do this as a PR, but I will need someone to sanity it as I only run CentOS.

@DanSheps commented on GitHub (Feb 15, 2019): contrib would have: contrib/netbox@.service contrib/netbox.env In the netbox.env, you have: ``` #WorkingDir='/usr/local/netbox/' #NBUser='www-data' #NBGroup='www-data' #PidPath='/var/run/netbox.pid' #Bind='127.0.0.1:8001' #Workers=3 #Timeout=120 #Log='/usr/local/netbox/netbox.log' ``` If @jeremystretch is willing, I can do this as a PR, but I will need someone to sanity it as I only run CentOS.

adam commented

@DanSheps commented on GitHub (Feb 15, 2019):

If someone could sanity check my last commit for ubuntu, I think that will work for most instances, I can submit a PR assuming this is approved.

@DanSheps commented on GitHub (Feb 15, 2019): If someone could sanity check my last commit for ubuntu, I think that will work for most instances, I can submit a PR assuming this is approved.

adam commented

@Grokzen commented on GitHub (Feb 20, 2019):

My 2 cents on this is that you should not replace this "yet". But instead to provide both solutions in the documentation for a period of time, but recommend/prefer the systemd solution.

@Grokzen commented on GitHub (Feb 20, 2019): My 2 cents on this is that you should not replace this "yet". But instead to provide both solutions in the documentation for a period of time, but recommend/prefer the systemd solution.

adam commented

@candlerb commented on GitHub (Feb 20, 2019):

Why? What's the benefit of supervisord?

@candlerb commented on GitHub (Feb 20, 2019): Why? What's the benefit of supervisord?

adam commented

@tb-killa commented on GitHub (Feb 20, 2019):

Why doesn't provide multiple install choices on documentation side and let the user select the right ones themselve ?
I think it's a bit of overhead to build all this stuff up because if someone is using netbox the person should know what he is doing.

@tb-killa commented on GitHub (Feb 20, 2019): Why doesn't provide multiple install choices on documentation side and let the user select the right ones themselve ? I think it's a bit of overhead to build all this stuff up because if someone is using netbox the person should know what he is doing.

adam commented

@candlerb commented on GitHub (Feb 20, 2019):

Why doesn't provide multiple install choices on documentation side

That was suggested in #2457, and rejected because of the overhead of maintaining two parallel sets of documentation.

I repeat: why is supervisord a better choice than systemd? Why not just document systemd, which is the standard for all mainstream Linux distributions? Then if as you say "the person should know what he is doing" they can install something else if they choose.

@candlerb commented on GitHub (Feb 20, 2019): > Why doesn't provide multiple install choices on documentation side That was suggested in #2457, and rejected because of the overhead of maintaining two parallel sets of documentation. I repeat: why is supervisord a better choice than systemd? Why not just document systemd, which is the standard for all mainstream Linux distributions? Then if as you say "the person should know what he is doing" they can install something else if they choose.

adam commented

@pobk commented on GitHub (Feb 21, 2019):

I would avoid putting any recommendations on system level processes entirely.

In answer to the question "why is supervisord better than systemd?": because supervisord is trying to do one job very well... unlike systemd which is trying to do all the jobs, but it's doing them badly. Case in point: systemd DNS resolver subsystem is very broken and does not comply with standard operational tennants. Also, why do you want your init system doing DHCP or managing your network or fiddling with your system clock? Why do you need it managing ALL THE THINGS?

Systemd is trying to undertake things, which personally, I believe the authors have little experience of, whereas the authors of things like syslog-ng or rsyslog, in the case of logging for example, have a great deal of experience in handling that data and their core remit is to handle ONLY that data...You don't see syslog-ng suddenly taking over DHCP-Client functions?

But back to my original point here: I can see a point for having a separate repo of init-scripts and docs around other extras for those who wish to contribute to in order to facilitate the installation of NetBox... I do not think systemd implementations should be a core part of the distribution/installation.

I've ansiblised NetBox on FreeBSD in an iocage. Systemd is (very thankfully) irrelevant in my environment.

@pobk commented on GitHub (Feb 21, 2019): I would avoid putting any recommendations on system level processes entirely. In answer to the question "why is supervisord better than systemd?": because supervisord is trying to do one job very well... unlike systemd which is trying to do all the jobs, but it's doing them badly. Case in point: systemd DNS resolver subsystem is very broken and does not comply with standard operational tennants. Also, why do you want your init system doing DHCP or managing your network or fiddling with your system clock? Why do you need it managing ALL THE THINGS? Systemd is trying to undertake things, which personally, I believe the authors have little experience of, whereas the authors of things like syslog-ng or rsyslog, in the case of logging for example, have a great deal of experience in handling that data and their core remit is to handle ONLY that data...You don't see syslog-ng suddenly taking over DHCP-Client functions? But back to my original point here: I can see a point for having a separate repo of init-scripts and docs around other extras for those who wish to contribute to in order to facilitate the installation of NetBox... I do not think systemd implementations should be a core part of the distribution/installation. I've ansiblised NetBox on FreeBSD in an iocage. Systemd is (very thankfully) irrelevant in my environment.

adam commented

@Grokzen commented on GitHub (Feb 21, 2019):

You can argue that since python2 still has one year left before EOL it can still be in but put into deprecated state and migrated out over time.

Another argument that can be done is that is not a good deprecation and migration strategy to rip the old out and replace it with something new right away within one major release cycle.

@Grokzen commented on GitHub (Feb 21, 2019): You can argue that since python2 still has one year left before EOL it can still be in but put into deprecated state and migrated out over time. Another argument that can be done is that is not a good deprecation and migration strategy to rip the old out and replace it with something new right away within one major release cycle.

adam commented

@candlerb commented on GitHub (Feb 21, 2019):

Another argument that can be done is that is not a good deprecation and migration strategy to rip the old out and replace it with something new right away within one major release cycle.

I am not suggesting that users should remove supervisord: I said to remove supervisord from the netbox documentation. Existing installations can continue to use supervisord without any changes.

In any case, neither supervisord nor systemd is part of netbox.

@candlerb commented on GitHub (Feb 21, 2019): > Another argument that can be done is that is not a good deprecation and migration strategy to rip the old out and replace it with something new right away within one major release cycle. I am not suggesting that users should remove supervisord: I said to remove supervisord *from the netbox documentation*. Existing installations can continue to use supervisord without any changes. In any case, neither supervisord nor systemd is part of netbox.

adam commented

@pobk commented on GitHub (Feb 21, 2019):

I am not suggesting that users should remove supervisord: I said to remove supervisord from the netbox documentation. Existing installations can continue to use supervisord without any changes.

In any case, neither supervisord nor systemd is part of netbox.

Agreed, although in defence of supervisord... It does abstract the process supervision away very nicely from any operating system requirements. Supervisord works on most *nix based operating systems I've worked with and the overall init system is abstracted away from the applications.

I've just checked... supervisord does have support for Py3 in development... From the github repo:

Supervisor is intended to work on Python 3 version 3.4 or later and on Python 2 version 2.7.

And also, from the supervisor issues list #1060 Python 3 support?

Looks like it is very much in progress and this issue is more of a non-issue.

@pobk commented on GitHub (Feb 21, 2019): > I am not suggesting that users should remove supervisord: I said to remove supervisord _from the netbox documentation_. Existing installations can continue to use supervisord without any changes. > > In any case, neither supervisord nor systemd is part of netbox. Agreed, although in defence of supervisord... It does abstract the process supervision away very nicely from any operating system requirements. Supervisord works on most *nix based operating systems I've worked with and the overall init system is abstracted away from the applications. I've just checked... supervisord does have support for Py3 in development... From the [github repo](https://github.com/Supervisor/supervisor): > Supervisor is intended to work on Python 3 version 3.4 or later and on Python 2 version 2.7. And also, from the supervisor issues list [#1060 Python 3 support?](https://github.com/Supervisor/supervisor/issues/1060) Looks like it is very much in progress and this issue is more of a non-issue.

adam commented

@kasimon commented on GitHub (Feb 21, 2019):

@pobk your systemd ranting is mostly unrelated to what this issue is about, please refrain from doing so. The systemd dns resolver for example has nothing to do with running netbox on a system.

@kasimon commented on GitHub (Feb 21, 2019): @pobk your systemd ranting is mostly unrelated to what this issue is about, please refrain from doing so. The systemd dns resolver for example has nothing to do with running netbox on a system.

adam commented

@kasimon commented on GitHub (Feb 21, 2019):

Let me add my 0.02 $currency: Currently, the setup documentation is specific to ubuntu 18.04 (which is using systemd). So I don't really see a point in installing additional software and running another service when what the system already contains is more than enough. This would certainly make the current documentation simpler and the resulting system a little bit easier to manage (the same management commands can be used that are already used for any other service on the system, no need to learn how to use supervisord).

One point that speaks for using supervisord in the documentation would be that it would make the documentation a little easier to be translated to other operating systems. But every freebsd (or non-linux/non-systemd) admin I know would have no problem to translate that simple systemd service description to something working on his/her system. And using a systemd service description in the documentation would make it easily translatable to almost any current mainstream linux distribution.

Summary: A systemd based setup would simplify the instructions without losing any features relevant to the scope of the document.

@kasimon commented on GitHub (Feb 21, 2019): Let me add my 0.02 $currency: Currently, the setup documentation is specific to ubuntu 18.04 (which is using systemd). So I don't really see a point in installing additional software and running another service when what the system already contains is more than enough. This would certainly make the current documentation simpler and the resulting system a little bit easier to manage (the same management commands can be used that are already used for any other service on the system, no need to learn how to use supervisord). One point that speaks for using supervisord in the documentation would be that it would make the documentation a little easier to be translated to other operating systems. But every freebsd (or non-linux/non-systemd) admin I know would have no problem to translate that simple systemd service description to something working on his/her system. And using a systemd service description in the documentation would make it easily translatable to almost any current mainstream linux distribution. Summary: A systemd based setup would simplify the instructions without losing any features relevant to the scope of the document.

adam commented

@DanSheps commented on GitHub (Feb 21, 2019):

I would avoid putting any recommendations on system level processes entirely.

Unfortunately, this is going to be part of the installation of almost any system, look at httpd, sql, etc. Most of them handle the automatic creation of the systemd or initd scripts. Netbox has no automatic installation

In answer to the question "why is supervisord better than systemd?": because supervisord is trying to do one job very well... unlike systemd which is trying to do all the jobs, but it's doing them badly. Case in point: systemd DNS resolver subsystem is very broken and does not comply with standard operational tennants. Also, why do you want your init system doing DHCP or managing your network or fiddling with your system clock? Why do you need it managing ALL THE THINGS?

I think there is a mis-understanding of what systemd is, and what it isn't.

systemd is a system configurator and service bootstrapper. It actually does very well with managing services and system configuration.

Systemd ... ... DHCP-Client functions?

systemd is not a single binary, it is actually composed of separate binaries in one project. So, when you refer to the "resolver", you are actually referring to "resolved". systemd-resolved it is a daemon made by the maker of systemd, and it is not enabled by default on CentOS7 (not sure about Ubuntu or any other flavours).

But back to my original point here: I can see a point for having a separate repo of init-scripts and docs around other extras for those who wish to contribute to in order to facilitate the installation of NetBox... I do not think systemd implementations should be a core part of the distribution/installation.

If you feel that way, I don't think supervisord should be included either. It is still a service bootstrapper.

I've ansiblised NetBox on FreeBSD in an iocage. Systemd is (very thankfully) irrelevant in my environment.

Your usage is most likely not mainstream. However, thankfully these instructions are not REQUIRED for netbox to function. If you want to go outside the setup docs, you are more or less on your own as far as getting it to work, which it sounds like you did anyways.

The main argument for using systemd, from what I can see, is it reduces a dependency from Netbox. Systemd is in most major Linux versions around now, so apart from BSD, systemd will be available on most systems running the software.

By removing supervisord, you also reduce the chance that there is a failure somewhere along the line. supervisord is also started by systemd on almost all systems covered by the installation docs. So all that is being done is removing a middleware that could potentially fail or introduce failures along the way.

@DanSheps commented on GitHub (Feb 21, 2019): > I would avoid putting any recommendations on system level processes entirely. Unfortunately, this is going to be part of the installation of almost any system, look at httpd, sql, etc. Most of them handle the automatic creation of the systemd or initd scripts. Netbox has no automatic installation > In answer to the question "why is supervisord better than systemd?": because supervisord is trying to do one job very well... unlike systemd which is trying to do all the jobs, but it's doing them badly. Case in point: systemd DNS resolver subsystem is very broken and does not comply with standard operational tennants. Also, why do you want your init system doing DHCP or managing your network or fiddling with your system clock? Why do you need it managing ALL THE THINGS? I think there is a mis-understanding of what systemd is, and what it isn't. systemd is a system configurator and service bootstrapper. It actually does very well with managing services and system configuration. > > Systemd ... ... DHCP-Client functions? systemd is not a single binary, it is actually composed of separate binaries in one project. So, when you refer to the "resolver", you are actually referring to "resolved". systemd-resolved it is a daemon made by the maker of systemd, and it is not enabled by default on CentOS7 (not sure about Ubuntu or any other flavours). > But back to my original point here: I can see a point for having a separate repo of init-scripts and docs around other extras for those who wish to contribute to in order to facilitate the installation of NetBox... I do not think systemd implementations should be a core part of the distribution/installation. If you feel that way, I don't think supervisord should be included either. It is still a service bootstrapper. > I've ansiblised NetBox on FreeBSD in an iocage. Systemd is (very thankfully) irrelevant in my environment. Your usage is most likely not mainstream. However, thankfully these instructions are not REQUIRED for netbox to function. If you want to go outside the setup docs, you are more or less on your own as far as getting it to work, which it sounds like you did anyways. The main argument for using systemd, from what I can see, is it reduces a dependency from Netbox. Systemd is in most major Linux versions around now, so apart from BSD, systemd will be available on most systems running the software. By removing supervisord, you also reduce the chance that there is a failure somewhere along the line. supervisord is also started by systemd on almost all systems covered by the installation docs. So all that is being done is removing a middleware that could potentially fail or introduce failures along the way.

adam commented

@DanSheps commented on GitHub (Feb 21, 2019):

@candlerb Thanks for taking a look and sanity checking the commit, I did a few more updates.

@DanSheps commented on GitHub (Feb 21, 2019): @candlerb Thanks for taking a look and sanity checking the commit, I did a few more updates.

adam commented

@pobk commented on GitHub (Feb 22, 2019):

@pobk your systemd ranting is mostly unrelated to what this issue is about, please refrain from doing so.

@kasimon: I would ask that you refrain grandstanding and throwing around admonishments at anyone as you have done to me. My systemd ranting, while very ranty and verbose (for which I will offer an apology), is related to the discussion and very much on-topic, whereas admonitions are irrelevant.

WIth respect to "FreeBSD admins will be able to translate systemd"... That's horrifically short sighted and exclusionist: Yes, why not make the documentation impenetrable to new engineers or those that aren't as experienced. Lets write documentation that focuses on a single OS.

The documentation already says:

The installation instructions provided here have been tested to work on Ubuntu 18.04 and CentOS 7.5. The particular commands needed to install dependencies on other distributions may vary significantly. Unfortunately, this is outside the control of the NetBox maintainers. Please consult your distribution's documentation for assistance with any errors.

Focusing the documentation even more on a singular init system is a poor idea.

Documenting the deployment process on Supervisord keeps things agnostic. You don't need Py3 support for Supervisor for netbox to function and you don't exclude non-linux OS users.

The alternative, as suggested elsewhere is to write specific integration guides elsewhere. I would be happy to write a BSD flavour if this is a viable alternative.

@pobk commented on GitHub (Feb 22, 2019): > @pobk your systemd ranting is mostly unrelated to what this issue is about, please refrain from doing so. @kasimon: I would ask that you refrain grandstanding and throwing around admonishments at anyone as you have done to me. My systemd ranting, while very ranty and verbose (for which I will offer an apology), is related to the discussion and very much on-topic, whereas admonitions are irrelevant. WIth respect to "FreeBSD admins will be able to translate systemd"... That's horrifically short sighted and exclusionist: Yes, why not make the documentation impenetrable to new engineers or those that aren't as experienced. Lets write documentation that focuses on a single OS. The documentation already says: > The installation instructions provided here have been tested to work on Ubuntu 18.04 and CentOS 7.5. The particular commands needed to install dependencies on other distributions may vary significantly. Unfortunately, this is outside the control of the NetBox maintainers. Please consult your distribution's documentation for assistance with any errors. Focusing the documentation even more on a singular init system is a poor idea. Documenting the deployment process on Supervisord keeps things agnostic. You don't need Py3 support for Supervisor for netbox to function and you don't exclude non-linux OS users. The alternative, as suggested elsewhere is to write specific integration guides elsewhere. I would be happy to write a BSD flavour if this is a viable alternative.

adam commented

@kasimon commented on GitHub (Feb 22, 2019):

@kasimon: I would ask that you refrain grandstanding and throwing around admonishments at anyone as you have done to me. My systemd ranting, while very ranty and verbose (for which I will offer an apology), is related to the discussion and very much on-topic, whereas admonitions are irrelevant.

I was a bit harsh, I'm sorry for that. Please let us all try to stay as close as possible to what this issue is about, there is more than enough room elsewhere on the net to have general systemd discussions.

WIth respect to "FreeBSD admins will be able to translate systemd"... That's horrifically short sighted and exclusionist: Yes, why not make the documentation impenetrable to new engineers or those that aren't as experienced. Lets write documentation that focuses on a single OS.

Well, netbox is not a very complicated program to install and to run. Providing an example documentation that will fit probably >90% of those needing help with their setup seems not a bad idea to me.

The documentation already says:

The installation instructions provided here have been tested to work on Ubuntu 18.04 and CentOS 7.5. The particular commands needed to install dependencies on other distributions may vary significantly. [...]

I was referring to https://netbox.readthedocs.io/en/stable/installation/3-http-daemon/:

For the sake of brevity, only Ubuntu 18.04 instructions are provided here, but this sort of web server and WSGI configuration is not unique to NetBox. Please consult your distribution's documentation for assistance if needed.

Which I think is a good way to handle this.

@kasimon commented on GitHub (Feb 22, 2019): > @kasimon: I would ask that you refrain grandstanding and throwing around admonishments at anyone as you have done to me. My systemd ranting, while very ranty and verbose (for which I will offer an apology), is related to the discussion and very much on-topic, whereas admonitions are irrelevant. I was a bit harsh, I'm sorry for that. Please let us all try to stay as close as possible to what this issue is about, there is more than enough room elsewhere on the net to have general systemd discussions. > WIth respect to "FreeBSD admins will be able to translate systemd"... That's horrifically short sighted and exclusionist: Yes, why not make the documentation impenetrable to new engineers or those that aren't as experienced. Lets write documentation that focuses on a single OS. Well, netbox is not a very complicated program to install and to run. Providing an example documentation that will fit probably >90% of those needing help with their setup seems not a bad idea to me. > The documentation already says: > > > The installation instructions provided here have been tested to work on Ubuntu 18.04 and CentOS 7.5. The particular commands needed to install dependencies on other distributions may vary significantly. [...] I was referring to https://netbox.readthedocs.io/en/stable/installation/3-http-daemon/: > For the sake of brevity, only Ubuntu 18.04 instructions are provided here, but this sort of web server and WSGI configuration is not unique to NetBox. Please consult your distribution's documentation for assistance if needed. Which I think is a good way to handle this.

adam commented

@pobk commented on GitHub (Feb 22, 2019):

I was a bit harsh, I'm sorry for that. Please let us all try to stay as close as possible to what this issue is about, there is more than enough room elsewhere on the net to have general systemd discussions.

Accepted and agreed.

Well, netbox is not a very complicated program to install and to run. Providing an example documentation that will fit probably >90% of those needing help with their setup seems not a bad idea to me.

It's not very complicated to us. Asking others might give you a different perspective.

I was referring to https://netbox.readthedocs.io/en/stable/installation/3-http-daemon/:

For the sake of brevity, only Ubuntu 18.04 instructions are provided here, but this sort of web server and WSGI configuration is not unique to NetBox. Please consult your distribution's documentation for assistance if needed.

Which I think is a good way to handle this.

For HTTPDs, I would agree entirely. What we are discussing here, however, is the supervisord/gunicorn side. My contention is:

describing a purely systemd implementation is a bad move.
supervisord is a useful container/runner which applies to all platforms
If you're going to document the systemd side of things, do so as a separate contrib docs which are not OS dependant.

@pobk commented on GitHub (Feb 22, 2019): > I was a bit harsh, I'm sorry for that. Please let us all try to stay as close as possible to what this issue is about, there is more than enough room elsewhere on the net to have general systemd discussions. Accepted and agreed. > Well, netbox is not a very complicated program to install and to run. Providing an example documentation that will fit probably >90% of those needing help with their setup seems not a bad idea to me. It's not very complicated to us. Asking others might give you a different perspective. > I was referring to https://netbox.readthedocs.io/en/stable/installation/3-http-daemon/: > > > For the sake of brevity, only Ubuntu 18.04 instructions are provided here, but this sort of web server and WSGI configuration is not unique to NetBox. Please consult your distribution's documentation for assistance if needed. > > Which I think is a good way to handle this. For HTTPDs, I would agree entirely. What we are discussing here, however, is the supervisord/gunicorn side. My contention is: 1. describing a purely systemd implementation is a bad move. 2. supervisord is a useful container/runner which applies to all platforms 3. If you're going to document the systemd side of things, do so as a separate contrib docs which are not OS dependant.

adam commented

@candlerb commented on GitHub (Feb 22, 2019):

2. supervisord is a useful container/runner which applies to all platforms

Each OS will have its own standard mechanism for starting/stopping processes, which happens to be systemd for those OSes mentioned in the documentation.

But I wouldn't recommend supervisord to anyone, for this reason alone:

Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3.

In other words, supervisord is abandonware. And pulling in legacy python2 as a dependency causes debugging headaches.

@candlerb commented on GitHub (Feb 22, 2019): > 2\. supervisord is a useful container/runner which applies to all platforms Each OS will have its own standard mechanism for starting/stopping processes, which happens to be systemd for those OSes mentioned in the documentation. But I wouldn't recommend supervisord to anyone, for [this reason alone](http://supervisord.org/introduction.html#platform-requirements): > Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3. In other words, supervisord is abandonware. And pulling in legacy python2 as a dependency causes [debugging headaches](https://groups.google.com/forum/#!topic/netbox-discuss/M5f_NOt_pb0).

adam commented

@pobk commented on GitHub (Feb 22, 2019):

supervisord is a useful container/runner which applies to all platforms

Each OS will have its own standard mechanism for starting/stopping processes, which happens to be systemd for those OSes mentioned in the documentation.

So remove it, instead of bleating on about some other poor software simply because a majority of users might be using an operating system that utilises it.

You're complaining about one "poor" piece of software and suggesting replacing it with another "poor" piece of software.

In other words, supervisord is abandonware. And pulling in legacy python2 as a dependency causes debugging headaches.

But as has been mentioned previously, they are working on that exact problem. It is very much not abandonware. Now you're just being sensationalist and obtuse.

And also, from the supervisor issues list #1060 Python 3 support?

@pobk commented on GitHub (Feb 22, 2019): > > 2. supervisord is a useful container/runner which applies to all platforms > > Each OS will have its own standard mechanism for starting/stopping processes, which happens to be systemd for those OSes mentioned in the documentation. So remove it, instead of bleating on about some other poor software simply because a majority of users might be using an operating system that utilises it. You're complaining about one "poor" piece of software and suggesting replacing it with another "poor" piece of software. > In other words, supervisord is abandonware. And pulling in legacy python2 as a dependency causes [debugging headaches](https://groups.google.com/forum/#!topic/netbox-discuss/M5f_NOt_pb0). But as has been mentioned previously, they are working on that exact problem. It is very much not abandonware. Now you're just being sensationalist and obtuse. > And also, from the supervisor issues list [#1060 Python 3 support?](https://github.com/Supervisor/supervisor/issues/1060)

adam commented

@mnaberez commented on GitHub (Apr 6, 2019):

Supervisor 4.0.0 (PyPI package; supports Python 3.4+ and 2.7)

@mnaberez commented on GitHub (Apr 6, 2019): [Supervisor 4.0.0](https://pypi.org/project/supervisor/) (PyPI package; supports Python 3.4+ and 2.7)

adam commented

@davidc commented on GitHub (Jul 8, 2019):

Ranting aside (I don't like systemd either), it is simply a fact that a lot of OSes ship with systemd as standard these days, whereas none that I know of ship with supervisord. Changing the default installation instructions to systemd would make sense - creating less work for the sysadmin installing Netbox and resulting in fewer packages installed. As has already been mentioned, a competent sysadmin could use whatever they wanted anyway, so this just makes the standard installation use-case simpler.

(Perhaps keep the old supervisor file and instructions in a contrib directory as already suggested).

@davidc commented on GitHub (Jul 8, 2019): Ranting aside (I don't like systemd either), it is simply a fact that a lot of OSes ship with systemd as standard these days, whereas none that I know of ship with supervisord. Changing the default installation instructions to systemd would make sense - creating less work for the sysadmin installing Netbox and resulting in fewer packages installed. As has already been mentioned, a competent sysadmin could use whatever they wanted anyway, so this just makes the standard installation use-case simpler. (Perhaps keep the old supervisor file and instructions in a contrib directory as already suggested).

adam commented