I don't like it when I cannot give a "complete" answer, so I did a bit more research. This time I did that using the documentation.

It's not posted on the docs.rws.com web site any more, but I found a source document for XPP Web Services 1.2 Installation and Release Notes. In that document it does talk about the init.d S92xppws startup script that gets delivered and installed into the init.d services on Linux for automatically starting Tomcat.

However, in the latest "install" document for XPP Web Services 1.3 I see that all of the discussions of the delivered and installed init.d service file on Linux was (consciously) removed.

I cannot say for sure (this goes back to 2013), but I'd guess that with the change to using an InstallAnywhere-based installer that the decision was made to no longer have the XPP WS installer do anything to deliver or install a startup script for Tomcat.

Or perhaps the change in "policy" wasn't really related to the change in how the installer worked, but it was just changed at the same time as changing the installer technology.

Perhaps more likely is that we found that with new versions of Tomcat that it became a "moving target" to try to keep up with how to correctly set up the init.d startup script, and/or that it didn't make sense for the XPP WS installer to be setting up a startup script for Tomcat since it is not an XPP-delivered product. After all, I believe that XPP WS is really just an "add on" to Tomcat in that we deliver files that then are used by the Tomcat "engine". Or maybe there was a "conflict" because the Tomcat installer was itself setting up a startup script.

Whereas AFAIK that is not true for XPP RESTful WS, where we deliver the "engine" as well as all the "helper" files and so the installer does deliver and install an init.d startup script (and this installer also is InstallAnywhere-based so the change for the XPP WS installer was not due to just that).

In any case, what I think we really missed doing was to add an explicit statement into the XPP Web Services 1.3 "install" document that the responsibility for setting up a startup script for Tomcat was (now) the user's responsibility (as the XPP WS installer would no longer do that), rather than only leaving it implied by having removed all the stuff about the startup script from it.

Anyway, hopefully that's a more "complete" answer.  

Jonathan, I love the "why" answer, and I completely relate to not being able to let go of things like this. I am legendary within Tweddle for sending explanations like yours in emails to people who will never read them (TL;DR). 

Anyway, it is the most helpful to know that I'm not going crazy. And I do understand from firsthand experience that S92xppws is a "moving target" ... the fickle nature of Java requirements and installations (and 32-bit vs 64-bit) being one of the bigger annoyances. It does need to start as a service in our environment; it is a conundrum for both of us that Tomcat is not a delivered product, but XPPWS as a Tomcat webapp is (requiring Tomcat to inherit certain XPP environment settings). We will figure it out now that we know more about what doesn't work, and why.

I would love to transition to RESTful WS, but we have so much invested in legacy code in Tridion Docs "publish to XPP" tools that we'd have to go through a major rewrite. Probably not going to happen on my watch (I am 64 and toying with the "R word").

Jonathan, I love the "why" answer, and I completely relate to not being able to let go of things like this. I am legendary within Tweddle for sending explanations like yours in emails to people who will never read them (TL;DR). 

Anyway, it is the most helpful to know that I'm not going crazy. And I do understand from firsthand experience that S92xppws is a "moving target" ... the fickle nature of Java requirements and installations (and 32-bit vs 64-bit) being one of the bigger annoyances. It does need to start as a service in our environment; it is a conundrum for both of us that Tomcat is not a delivered product, but XPPWS as a Tomcat webapp is (requiring Tomcat to inherit certain XPP environment settings). We will figure it out now that we know more about what doesn't work, and why.

I would love to transition to RESTful WS, but we have so much invested in legacy code in Tridion Docs "publish to XPP" tools that we'd have to go through a major rewrite. Probably not going to happen on my watch (I am 64 and toying with the "R word").