As I said about CentOS 7:
You're using Debian 8. You have systemd.
/etc/rc.local is a double backwards compatibility mechanism in systemd, because it is a backwards compatibility mechanism for a mechanism that was itself a compatibility mechanism in the van Smoorenburg System 5
As shown by the mess in the AskUbuntu question hyperlinked below, using
/etc/rc.local can go horribly wrong. Elsewhere, people have been surprised by the fact that systemd doesn't run
rc.local in the quite the same way, in quite the same place in the bootstrap, as they are used to. Others have been surprised by the fact that what they set up in
rc.local expecting the old ways of doing things is then completely undone by the likes of new
udev rules, NetworkManager,
systemd-resolved, or various "Kit"s.
rc.local. It's not the way to go. You have Debian 8. So make a proper systemd service unit, and don't begin from a point that is two levels of backwards compatibility away. (On Ubuntu, it is three times removed, the System 5
rc clone that followed it having then been itself twice superseded, over a decade ago by upstart and then by systemd.)
Don't start the process of running this with systemd by making a
startup.sh script and then invoking that from a systemd service unit. That idea leads very quickly into systemd House of Horror territory. Make a service unit that describes as much as possible of the process setup and execution directly, itself. Use a wrapper shell script only when you hit the limitations of that. And make sure that your wrapper shell script at the very minimum uses
exec to overlay the final dæmon program.
You don't say what that service is. You mention using
screen, but that is too often abused as a Poor Man's Dæmon Supervisor and may well be not the way to run your service under an actual service manager. I do see the word "ark" in there, which in conjunction with potential abuse of
screen brings to mind two things: