I have several systemd services which I want to run as a user (i.e.
not root) but I do want them to run at start-up whenever the system is rebooted.

I have the service files in ~/.config/systemd/user, one of them is as
follows:-

[Unit]
Description=Run the helm display

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -lc /home/chris/bin/helmlcd.py
Restart=on-failure
RemainAfterExit=yes


[Install]
WantedBy=multi-user.target

I now see why it doesn't work, the 'user bus' doesn't have a
multi-user.target link. The default answer seems to be to start the
service as a system service but that needs root access doesn't it?

Is running the service as a system service (presumably with 'User=%1'
in the service file the only way to do this? Or is there a way to get
a user service to always run at boot time?


--
Chris Green
ú

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, Feb 27, 2026 at 10:26:08 +0000, Chris Green wrote:

I have several systemd services which I want to run as a user (i.e.
not root) but I do want them to run at start-up whenever the system is rebooted.

Look for the User= directive in systemd.exec(5).

I have the service files in ~/.config/systemd/user, one of them is as follows:-

Those services are only started when that user logs in. Not what you want.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Fri, Feb 27, 2026 at 10:26:08AM +0000, Chris Green wrote:

I have several systemd services which I want to run as a user (i.e.
not root) but I do want them to run at start-up whenever the system is rebooted.

User services normally only start when the user logs in for the first
time, and are terminated when the last login session of the user ends.

If you would like fore there to always be a session of that user
existing (so all of that user's services start at boot and remain
running), you can enable "linger":

$ loginctl enable-linger

If the service in question is not strictly user-based then I would
probably run it as a system service with User=. e.g. a daemon that you
expect there to only be one of on the system, that runs under a specific
user for that daemon, would make more sense as a system service, whereas something that runs on behalf of a specific real user (and there might
be other instances of per-user) does make sense as a user service.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Andy Smith <andy@strugglers.net> wrote:

Hi,

On Fri, Feb 27, 2026 at 10:26:08AM +0000, Chris Green wrote:

I have several systemd services which I want to run as a user (i.e.
not root) but I do want them to run at start-up whenever the system is rebooted.

User services normally only start when the user logs in for the first
time, and are terminated when the last login session of the user ends.

If you would like fore there to always be a session of that user
existing (so all of that user's services start at boot and remain
running), you can enable "linger":

$ loginctl enable-linger

If the service in question is not strictly user-based then I would
probably run it as a system service with User=. e.g. a daemon that you
expect there to only be one of on the system, that runs under a specific
user for that daemon, would make more sense as a system service, whereas something that runs on behalf of a specific real user (and there might
be other instances of per-user) does make sense as a user service.

Thank you Andy. I think enable-linger may well be just what I want
for some services.

This is a small system that is on a boat in France, it drives some
displays on the boat and also allows for remote monitoring of battery
voltages and such.

The systemd services in question are of two types:-

1 - A collection of outgoing ssh connections which set up reverse
tunnels so that I can log in to the system using ssh from home. (The
system on the boat is behind a CGNAT mobile connection).

2 - Some python programs that run the displays on the boat.

Neither of the above need root access but I do want them to run
whenever the system is on, not just when I'm logged in.

--
Chris Green
ú

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Chris Green <cl@isbd.net> writes:

The systemd services in question are of two types:-

1 - A collection of outgoing ssh connections which set up reverse
tunnels so that I can log in to the system using ssh from home. (The
system on the boat is behind a CGNAT mobile connection).

2 - Some python programs that run the displays on the boat.

Neither of the above need root access but I do want them to run
whenever the system is on, not just when I'm logged in.

I would recommend that you create a dedicated user for the services
instead of utilizing your personal account, or consider using the
DynamicUser setting of systemd.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Henrik Ahlgren <pablo@seestieto.com> wrote:

Chris Green <cl@isbd.net> writes:

The systemd services in question are of two types:-

1 - A collection of outgoing ssh connections which set up reverse
tunnels so that I can log in to the system using ssh from home. (The
system on the boat is behind a CGNAT mobile connection).

2 - Some python programs that run the displays on the boat.

Neither of the above need root access but I do want them to run
whenever the system is on, not just when I'm logged in.

I would recommend that you create a dedicated user for the services
instead of utilizing your personal account, or consider using the DynamicUser setting of systemd.

What would be the advantage? I am the only 'real' user on the system
and it's almost certainly going to stay that way for as long as I'm
around (which won't be all that long as I'm approaching 80 years old).

The system doesn't have much else to do, it's dedicated to the above
tasks plus automatically sending some data back home.

--
Chris Green
ú

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Chris Green (HE12026-02-28):

1 - A collection of outgoing ssh connections which set up reverse
tunnels so that I can log in to the system using ssh from home. (The
system on the boat is behind a CGNAT mobile connection).

The service that provides network connectivity to your SSH daemon, a
system service, should run as a system service.

As a side note, you should consider complementing these tunnels with a
VPN (or several): VPN software is designed for that, keeping the
connections alive will be easier and more robust.

2 - Some python programs that run the displays on the boat.

For that, I would recommend to set the user running the display on
auto-login in a lightweight display manager.

(nodm was not very reliable when I used it.)

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Nicolas George <george@nsup.org> wrote:

Chris Green (HE12026-02-28):

1 - A collection of outgoing ssh connections which set up reverse
tunnels so that I can log in to the system using ssh from home. (The
system on the boat is behind a CGNAT mobile connection).

The service that provides network connectivity to your SSH daemon, a
system service, should run as a system service.

As a side note, you should consider complementing these tunnels with a
VPN (or several): VPN software is designed for that, keeping the
connections alive will be easier and more robust.

2 - Some python programs that run the displays on the boat.

For that, I would recommend to set the user running the display on
auto-login in a lightweight display manager.

It's a headless system so there's no display manager.

--
Chris Green
ú

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Chris Green (HE12026-03-01):

2 - Some python programs that run the displays on the boat.

^^^^^^^^^^^^^^^^^^^^

For that, I would recommend to set the user running the display on auto-login in a lightweight display manager.

It's a headless system so there's no display manager.

I am confused. Can you explain how a headless system has displays?

Regards,

--
Nicolas George

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Nicolas George <george@nsup.org> wrote:

Chris Green (HE12026-03-01):

2 - Some python programs that run the displays on the boat.

^^^^^^^^^^^^^^^^^^^^

For that, I would recommend to set the user running the display on auto-login in a lightweight display manager.

It's a headless system so there's no display manager.

I am confused. Can you explain how a headless system has displays?

:-) The displays are LCD character displays on the boat's instrument
panel. They are driven via an I2C bus.

--
Chris Green
ú

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Chris Green (HE12026-03-01):

:-) The displays are LCD character displays on the boat's instrument
panel. They are driven via an I2C bus.

Ok, my bad. But then, driving them is just another system service. Or
system services, plural, one per display.

Regards,

--
Nicolas George

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)