Ubuntu – How to read systemd journal file on system that has no systemd

First problem

You can specify the directives User= and Group= in the [Service] section of the unit file.

Second problem

To make the service run on boot, you should not put it in your home folder. Instead, put it under /etc/systemd/system/. This is the folder meant to be used by the system administrator (i.e. you) to add new system-wide services.

Other folders include:

• /usr/lib/systemd/system/ is meant for packages which want to install unit files, though under Debian and Ubuntu the folder is actually /lib/systemd/system/ because the various bin and lib folders have not been merged into a unified /usr/ prefix yet.
• /usr/local/systemd/system/ is for installing units by locally compiled packages.

Testing the unit

Once the unit file is in an appropriate location, you can try starting the unit immediately by typing systemctl start <UNIT_FILENAME> as usual. It should work without having to type the unit's full path. The extension also doesn't have to be specified if it's .service.

Enabling the unit

Before you can enable your unit, you need to add an [Install] section, under which you should add the directive WantedBy=multi-user.target. This directive specifies the stage of the boot-up process during which the service should be started (if it were enabled). multi-user.target is appropriate for most services.

Once that information is added, you can use systemctl enable <UNIT_FILENAME>, which enables the unit, making systemd from now on automatically start it during boot up at the specified stage.

Ubuntu has tens of thousands of files you don't need but are not worth trying to get rid of.

Ubuntu is really an ecosystem of packages. Some of those packages have also switched to systemd, but others may use Upstart, SysV init scripts or cron jobs. You could turn off cron jobs and it might not break anything right away, but you later might end up installing something which expects cron jobs to be running. That said, you can disable cron jobs like this as long as you willing to accept that some things that expect to run might not be run:

 sudo update-rc.d foobar disable

Likewise, some packages may expect to log to syslog instead of the journal. You can remove rsyslog with:

 sudo apt-get remove rsyslog

But I wouldn't recommend doing that either. I think the adage applies: "Benchmark first, then optimize." First find out what's actually slowing down your system in a meaningful way and work on fixing that. I doubt that cron or rsyslog will be your biggest problems.