TLDR: "jobs" represent requested state changes of "services" or other systemd units. They only exist while a service is starting/stopping/restarting/etc.
Services
In systemd parlance "services" are supervised process groups, (primarily) defined through .service unit configuration files.
Every service (like any other systemd unit type) has a state, as described in the man page systemd (1):
Units may be "active" (meaning started, bound, plugged in, …, depending on the unit type, see below), or "inactive" (meaning stopped, unbound, unplugged, …), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called "activating", "deactivating"). A special "failed" state is available as well, which is very similar to "inactive" and is entered when the service failed in some way (process returned error code on exit, or crashed, an operation timed out, or after too many restarts). If this state is entered, the cause will be logged, for later reference. Note that the various unit types may have a number of additional substates, which are mapped to the five generalized unit states described here.
(By now "reloading" and "maintenance" were added to the five unit states, so there are seven in total, but that doesn't change much)
systemctl list-units --type=service --state=running displays all services that are in the "running" substate of the "active" state and thus finished activating.
Jobs
"Jobs" are state change requests to systemd. They only exist in RAM and only as long as the request is being processed.
What happens when a state change is requested (on boot or shutdown, using systemctl start, systemctl stop, etc.) is outlined in systemd's original design document:
if a unit is requested to start up or shut down we will add it and all its dependencies to a temporary transaction. Then, we will verify if the transaction is consistent (i.e. whether the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop. Also, systemd tries to suppress non-essential jobs in the transaction that would stop a running service. Non-essential jobs are those which the original request did not directly include but which where pulled in by Wants type of dependencies. Finally we check whether the jobs of the transaction contradict jobs that have already been queued, and optionally the transaction is aborted then. If all worked out and the transaction is consistent and minimized in its impact it is merged with all already outstanding jobs and added to the run queue.
Essentially, while e.g. systemctl start ssh.service is running, start jobs for ssh.service and all of its (not yet running) dependencies are created and the unit ssh.service is put into the "activating" state.
You'll see these jobs in the output of systemctl list-jobs as long as the service has not finished starting or a job that was essential for the state change failed. After that the service is put into the "active" or "failed" state.
