Functionally, there is no difference between any of these invocation methods.

start and stop are symbolic links to initctl. service is a shell script that determines whether to execute the init script or use initctl.

The simplest way to see what is an Upstart job is to take a look at /etc/init/. Everything in there is an Upstart job. If you ls -l /etc/init.d/ you'll see every service and system task. The SysV init jobs will be real files, while the Upstart jobs will be symlinks to /lib/init/upstart-job which will properly invoke the Upstart job.

In other words, you can also invoke Upstart jobs by calling, for example, /etc/init.d/apport restart, though the output will suggest using service, start, or stop instead.

So, in practice it makes no difference (yet!). But if I were scripting something, I would certainly use service, start, or stop as there is almost no chance that will deprecated, whereas calling services through /etc/init.d/ could go away down the road (though probably not any time soon).

A note on disabling services: renaming the .conf file works, but I don't recommend it. You might disable a service that way, but if there is a package upgrade available, dpkg will copy down a fresh copy of the Upstart job and without intending it, your service is enabled again. The correct way to disable an Upstart job is to use a .override file which leaves the original job intact.

For example, to disable apport, simply create a file called /etc/init/apport.override that contains the word "manual".

# echo "manual" > /etc/init/apport.override

Personally, I would avoid using sysv-rc-conf. It may be safe enough to use it to modify SysV jobs, but I'm not sure; it doesn't seem to support Upstart jobs, and there's no way to tell form the interface which is which. I would stick with update-rc.d for managing SysV scripts.

For more Upstart information see:

1. The Upstart Cookbook: http://upstart.ubuntu.com/cookbook/
2. The command man 5 init: http://manpages.ubuntu.com/manpages/precise/en/man5/init.5.html

Firstly, there should be zero reason to login as the tomcat7 user. There's no logical use case for this, so therefore I'm not sure why you'd try and use it.

You state in your question you want to set up a virtual X server for a webapp - you don't need to login as tomcat7 to do this, though your question isn't "How can I launch a virtual X server for my web app as tomcat7 without logging in", so don't expect help here with that in this question.

Having said this, it's likely that this is a System User Account and not an actual user; these users typically have no passwords associated with it, as it is designed to be used by system daemons and services, rather than users. Therefore, you cannot login as that user as it isn't designed to be logged into by users - to use the user, you have to use su to switch user to it, and you have to do so as superuser or root or with sudo. Also note that there's the option of setting a password, but it's ill-advised to do so, for that user.

Option 1 (Recommended, and the Proper Way to do this): su as sudo or root/superuser

You will need to have sudo power, or access to the root user to get this working with these instructions.

With sudo:

sudo su tomcat7

As root user:

su tomcat7

Option 2 (NOT RECOMMENDED, because it introduces security concerns and other issues): Set a password

You will need to have sudo power, or access to the root user to get this working with these instructions, and it is VERY likely you will break things by doing this. I HIGHLY RECOMMEND not doing this!

Set a password.

With sudo:

sudo passwd tomcat7
[set a password with the prompts]

As root:

passwd tomcat7

Once the password is set, then you can just login to the user (either via SSH or the console directly).

Again, I strongly recommend that you do not do this method - this could break Tomcat7, and can actually put your system at risk because someone can now brute-force the password and have access to the tomcat instance as the tomcat user itself.

To reiterate though: there is no logical reason to need to login as the tomcat7 user. Do so at your own risk as you can affect evilness on your system if you're not careful.