Automatically enable systemd services installed using deb?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I'm building a bunch of services to install on my own (automatically created) servers. I'm migrating from upstart on Ubuntu 14.04, where services are enabled by default (we have to do extra work if we don't want then to start when installed), to Ubuntu 16.04 where we want to use systemd as the new native service framework.
The services are installed using deb packages that I'm creating myself. I've upgraded the deb creation by adding --with systemd
to rules
and adding a package-name.service
with a systemd unit specification.
The problem I found is that even if I add an [Install]
section with WantedBy=multi-user.target
, the service will not be started on the system.
Instead, the service gets installed and then systemctl status package-name
shows:
â package-name.service - My Service
Loaded: loaded (/lib/systemd/system/package-name.service; disabled; vendor preset: enabled)
Active: inactive (dead)
I don't have any systemd overrides in my rules
, which as I've understood from the Debian packaging with systemd page as well as the dh_systemd_enable man page I can use to not enable services if I choose not to.
Also from the looks of the status display it appears that dh-systemd
did enable the services (the vendor preset bit), but that was not enough. What am I missing?
ubuntu systemd services deb
add a comment |Â
up vote
3
down vote
favorite
I'm building a bunch of services to install on my own (automatically created) servers. I'm migrating from upstart on Ubuntu 14.04, where services are enabled by default (we have to do extra work if we don't want then to start when installed), to Ubuntu 16.04 where we want to use systemd as the new native service framework.
The services are installed using deb packages that I'm creating myself. I've upgraded the deb creation by adding --with systemd
to rules
and adding a package-name.service
with a systemd unit specification.
The problem I found is that even if I add an [Install]
section with WantedBy=multi-user.target
, the service will not be started on the system.
Instead, the service gets installed and then systemctl status package-name
shows:
â package-name.service - My Service
Loaded: loaded (/lib/systemd/system/package-name.service; disabled; vendor preset: enabled)
Active: inactive (dead)
I don't have any systemd overrides in my rules
, which as I've understood from the Debian packaging with systemd page as well as the dh_systemd_enable man page I can use to not enable services if I choose not to.
Also from the looks of the status display it appears that dh-systemd
did enable the services (the vendor preset bit), but that was not enough. What am I missing?
ubuntu systemd services deb
I've worked around the problem by callingdh_systemd_enable
(to make the service run by default) anddh_systemd_start
(to actually start it after installation) manually from theoverride_dh_auto_install
target inrules
, but I still don't understand why it doesn't get called automatically - as promised in its documentation.
â Guss
Apr 6 '16 at 11:51
I haven't worked with.deb
packages, but I have worked with custom.rpm
packages that I wanted to enable a service for. Withrpm
s there's apost
section, which will just run the commands in it after install is finished. That's where I threw in asystemctl enable
. I assume.deb
has something similar.
â Centimane
Jul 5 '17 at 12:58
dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - thedh_auto_install
step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)
â Guss
Jul 5 '17 at 14:05
1
You need 3 things:rules
to containdh $@ --with systemd
,control
to containBuild-Depends: dh-systemd
,postinst
to contain#DEBHELPER#
and a reasonable current build system
â Tino
Oct 1 at 13:40
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I'm building a bunch of services to install on my own (automatically created) servers. I'm migrating from upstart on Ubuntu 14.04, where services are enabled by default (we have to do extra work if we don't want then to start when installed), to Ubuntu 16.04 where we want to use systemd as the new native service framework.
The services are installed using deb packages that I'm creating myself. I've upgraded the deb creation by adding --with systemd
to rules
and adding a package-name.service
with a systemd unit specification.
The problem I found is that even if I add an [Install]
section with WantedBy=multi-user.target
, the service will not be started on the system.
Instead, the service gets installed and then systemctl status package-name
shows:
â package-name.service - My Service
Loaded: loaded (/lib/systemd/system/package-name.service; disabled; vendor preset: enabled)
Active: inactive (dead)
I don't have any systemd overrides in my rules
, which as I've understood from the Debian packaging with systemd page as well as the dh_systemd_enable man page I can use to not enable services if I choose not to.
Also from the looks of the status display it appears that dh-systemd
did enable the services (the vendor preset bit), but that was not enough. What am I missing?
ubuntu systemd services deb
I'm building a bunch of services to install on my own (automatically created) servers. I'm migrating from upstart on Ubuntu 14.04, where services are enabled by default (we have to do extra work if we don't want then to start when installed), to Ubuntu 16.04 where we want to use systemd as the new native service framework.
The services are installed using deb packages that I'm creating myself. I've upgraded the deb creation by adding --with systemd
to rules
and adding a package-name.service
with a systemd unit specification.
The problem I found is that even if I add an [Install]
section with WantedBy=multi-user.target
, the service will not be started on the system.
Instead, the service gets installed and then systemctl status package-name
shows:
â package-name.service - My Service
Loaded: loaded (/lib/systemd/system/package-name.service; disabled; vendor preset: enabled)
Active: inactive (dead)
I don't have any systemd overrides in my rules
, which as I've understood from the Debian packaging with systemd page as well as the dh_systemd_enable man page I can use to not enable services if I choose not to.
Also from the looks of the status display it appears that dh-systemd
did enable the services (the vendor preset bit), but that was not enough. What am I missing?
ubuntu systemd services deb
ubuntu systemd services deb
edited Apr 6 '16 at 9:19
Jeff Schaller
35.1k952115
35.1k952115
asked Apr 6 '16 at 8:20
Guss
5,86111224
5,86111224
I've worked around the problem by callingdh_systemd_enable
(to make the service run by default) anddh_systemd_start
(to actually start it after installation) manually from theoverride_dh_auto_install
target inrules
, but I still don't understand why it doesn't get called automatically - as promised in its documentation.
â Guss
Apr 6 '16 at 11:51
I haven't worked with.deb
packages, but I have worked with custom.rpm
packages that I wanted to enable a service for. Withrpm
s there's apost
section, which will just run the commands in it after install is finished. That's where I threw in asystemctl enable
. I assume.deb
has something similar.
â Centimane
Jul 5 '17 at 12:58
dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - thedh_auto_install
step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)
â Guss
Jul 5 '17 at 14:05
1
You need 3 things:rules
to containdh $@ --with systemd
,control
to containBuild-Depends: dh-systemd
,postinst
to contain#DEBHELPER#
and a reasonable current build system
â Tino
Oct 1 at 13:40
add a comment |Â
I've worked around the problem by callingdh_systemd_enable
(to make the service run by default) anddh_systemd_start
(to actually start it after installation) manually from theoverride_dh_auto_install
target inrules
, but I still don't understand why it doesn't get called automatically - as promised in its documentation.
â Guss
Apr 6 '16 at 11:51
I haven't worked with.deb
packages, but I have worked with custom.rpm
packages that I wanted to enable a service for. Withrpm
s there's apost
section, which will just run the commands in it after install is finished. That's where I threw in asystemctl enable
. I assume.deb
has something similar.
â Centimane
Jul 5 '17 at 12:58
dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - thedh_auto_install
step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)
â Guss
Jul 5 '17 at 14:05
1
You need 3 things:rules
to containdh $@ --with systemd
,control
to containBuild-Depends: dh-systemd
,postinst
to contain#DEBHELPER#
and a reasonable current build system
â Tino
Oct 1 at 13:40
I've worked around the problem by calling
dh_systemd_enable
(to make the service run by default) and dh_systemd_start
(to actually start it after installation) manually from the override_dh_auto_install
target in rules
, but I still don't understand why it doesn't get called automatically - as promised in its documentation.â Guss
Apr 6 '16 at 11:51
I've worked around the problem by calling
dh_systemd_enable
(to make the service run by default) and dh_systemd_start
(to actually start it after installation) manually from the override_dh_auto_install
target in rules
, but I still don't understand why it doesn't get called automatically - as promised in its documentation.â Guss
Apr 6 '16 at 11:51
I haven't worked with
.deb
packages, but I have worked with custom .rpm
packages that I wanted to enable a service for. With rpm
s there's a post
section, which will just run the commands in it after install is finished. That's where I threw in a systemctl enable
. I assume .deb
has something similar.â Centimane
Jul 5 '17 at 12:58
I haven't worked with
.deb
packages, but I have worked with custom .rpm
packages that I wanted to enable a service for. With rpm
s there's a post
section, which will just run the commands in it after install is finished. That's where I threw in a systemctl enable
. I assume .deb
has something similar.â Centimane
Jul 5 '17 at 12:58
dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - the
dh_auto_install
step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)â Guss
Jul 5 '17 at 14:05
dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - the
dh_auto_install
step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)â Guss
Jul 5 '17 at 14:05
1
1
You need 3 things:
rules
to contain dh $@ --with systemd
, control
to contain Build-Depends: dh-systemd
, postinst
to contain #DEBHELPER#
and a reasonable current build systemâ Tino
Oct 1 at 13:40
You need 3 things:
rules
to contain dh $@ --with systemd
, control
to contain Build-Depends: dh-systemd
, postinst
to contain #DEBHELPER#
and a reasonable current build systemâ Tino
Oct 1 at 13:40
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
4
down vote
Actually, you don't need to add anything in override_dh_auto_install
.
You need --with systemd
(without the dash between with
and systemd
) in the rules
and the package dh-systemd
installed.
This is the correct answer.
â Tino
Oct 1 at 13:35
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overridingdh_auto_install
to calldh_sysyemd_enable
anddh_systemd_start
is the best way I could find except writing a postinst script manually.
â Guss
Oct 1 at 15:02
add a comment |Â
up vote
1
down vote
accepted
I've worked around the problem by calling dh_systemd_enable (to make the service run by default) and dh_systemd_start (to actually start it after installation) manually from the override_dh_auto_install target in rules, so it looks like this:
%:
dh $@ --with-systemd
override_dh_auto_install:
dh_auto_install
dh_systemd_enable || true
dh_systemd_start || true
1
For me, with the--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, yourpostinst
script may be missing the#DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)
â Alexis Wilke
Aug 14 at 4:11
add a comment |Â
up vote
0
down vote
I ran into this issue as well. It turns out that dh_systemd_enable
has certain expectations about the content of a foo.service
file.
You can see this in lines 187-215 of deb-systemd-helper.
In particular, ensuring that the foo.service
file has an [Install]
section and has at least an Alias
field where the alias does NOT equal foo.service
will cause the call to deb-systemd-helper enable
to detect the needed service. If you want the service to be automatically started adding WantedBy=multi-user.target
is also needed.
Below is a lightly modified version of my foo.service
file:
[Unit]
Description=foo service, foos
After=bar.service
Requires=bar.service
[Service]
ExecStart=/path/to/my/script/foo
Restart=always
RestartSec=5
[Install]
Alias=foo
WantedBy=multi-user.target
I was able to determine this by enabling a couple debug flags and adding debug statements in the deb-systemd-helper
perl script. On an Ubuntu 16.04 system I found it here: /usr/bin/deb-systemd-helper
.
So repeatedly running the following and adding debug statements got me to the bottom of the problem.
$ sudo DPKG_MAINTSCRIPT_PACKAGE=1 _DEB_SYSTEMD_HELPER_DEBUG=1 deb-systemd-helper enable foo.service
New contributor
It looks like theAlias
line causesdeb-systemd-helper
to create a link to/etc/systemd/system
- which is not necessarily what I want. Can you show what you have inrules
other than%: dh $@ --with-systemd
to get your service auto-enabled and started?
â Guss
yesterday
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
Actually, you don't need to add anything in override_dh_auto_install
.
You need --with systemd
(without the dash between with
and systemd
) in the rules
and the package dh-systemd
installed.
This is the correct answer.
â Tino
Oct 1 at 13:35
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overridingdh_auto_install
to calldh_sysyemd_enable
anddh_systemd_start
is the best way I could find except writing a postinst script manually.
â Guss
Oct 1 at 15:02
add a comment |Â
up vote
4
down vote
Actually, you don't need to add anything in override_dh_auto_install
.
You need --with systemd
(without the dash between with
and systemd
) in the rules
and the package dh-systemd
installed.
This is the correct answer.
â Tino
Oct 1 at 13:35
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overridingdh_auto_install
to calldh_sysyemd_enable
anddh_systemd_start
is the best way I could find except writing a postinst script manually.
â Guss
Oct 1 at 15:02
add a comment |Â
up vote
4
down vote
up vote
4
down vote
Actually, you don't need to add anything in override_dh_auto_install
.
You need --with systemd
(without the dash between with
and systemd
) in the rules
and the package dh-systemd
installed.
Actually, you don't need to add anything in override_dh_auto_install
.
You need --with systemd
(without the dash between with
and systemd
) in the rules
and the package dh-systemd
installed.
edited Aug 1 '17 at 21:36
answered Aug 1 '17 at 20:21
sduthil
1013
1013
This is the correct answer.
â Tino
Oct 1 at 13:35
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overridingdh_auto_install
to calldh_sysyemd_enable
anddh_systemd_start
is the best way I could find except writing a postinst script manually.
â Guss
Oct 1 at 15:02
add a comment |Â
This is the correct answer.
â Tino
Oct 1 at 13:35
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overridingdh_auto_install
to calldh_sysyemd_enable
anddh_systemd_start
is the best way I could find except writing a postinst script manually.
â Guss
Oct 1 at 15:02
This is the correct answer.
â Tino
Oct 1 at 13:35
This is the correct answer.
â Tino
Oct 1 at 13:35
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overriding
dh_auto_install
to call dh_sysyemd_enable
and dh_systemd_start
is the best way I could find except writing a postinst script manually.â Guss
Oct 1 at 15:02
Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overriding
dh_auto_install
to call dh_sysyemd_enable
and dh_systemd_start
is the best way I could find except writing a postinst script manually.â Guss
Oct 1 at 15:02
add a comment |Â
up vote
1
down vote
accepted
I've worked around the problem by calling dh_systemd_enable (to make the service run by default) and dh_systemd_start (to actually start it after installation) manually from the override_dh_auto_install target in rules, so it looks like this:
%:
dh $@ --with-systemd
override_dh_auto_install:
dh_auto_install
dh_systemd_enable || true
dh_systemd_start || true
1
For me, with the--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, yourpostinst
script may be missing the#DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)
â Alexis Wilke
Aug 14 at 4:11
add a comment |Â
up vote
1
down vote
accepted
I've worked around the problem by calling dh_systemd_enable (to make the service run by default) and dh_systemd_start (to actually start it after installation) manually from the override_dh_auto_install target in rules, so it looks like this:
%:
dh $@ --with-systemd
override_dh_auto_install:
dh_auto_install
dh_systemd_enable || true
dh_systemd_start || true
1
For me, with the--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, yourpostinst
script may be missing the#DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)
â Alexis Wilke
Aug 14 at 4:11
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I've worked around the problem by calling dh_systemd_enable (to make the service run by default) and dh_systemd_start (to actually start it after installation) manually from the override_dh_auto_install target in rules, so it looks like this:
%:
dh $@ --with-systemd
override_dh_auto_install:
dh_auto_install
dh_systemd_enable || true
dh_systemd_start || true
I've worked around the problem by calling dh_systemd_enable (to make the service run by default) and dh_systemd_start (to actually start it after installation) manually from the override_dh_auto_install target in rules, so it looks like this:
%:
dh $@ --with-systemd
override_dh_auto_install:
dh_auto_install
dh_systemd_enable || true
dh_systemd_start || true
answered Jul 5 '17 at 14:08
Guss
5,86111224
5,86111224
1
For me, with the--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, yourpostinst
script may be missing the#DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)
â Alexis Wilke
Aug 14 at 4:11
add a comment |Â
1
For me, with the--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, yourpostinst
script may be missing the#DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)
â Alexis Wilke
Aug 14 at 4:11
1
1
For me, with the
--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, your postinst
script may be missing the #DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)â Alexis Wilke
Aug 14 at 4:11
For me, with the
--with-systemd
the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, your postinst
script may be missing the #DEBHELPER#
(See unix.stackexchange.com/questions/423069/â¦)â Alexis Wilke
Aug 14 at 4:11
add a comment |Â
up vote
0
down vote
I ran into this issue as well. It turns out that dh_systemd_enable
has certain expectations about the content of a foo.service
file.
You can see this in lines 187-215 of deb-systemd-helper.
In particular, ensuring that the foo.service
file has an [Install]
section and has at least an Alias
field where the alias does NOT equal foo.service
will cause the call to deb-systemd-helper enable
to detect the needed service. If you want the service to be automatically started adding WantedBy=multi-user.target
is also needed.
Below is a lightly modified version of my foo.service
file:
[Unit]
Description=foo service, foos
After=bar.service
Requires=bar.service
[Service]
ExecStart=/path/to/my/script/foo
Restart=always
RestartSec=5
[Install]
Alias=foo
WantedBy=multi-user.target
I was able to determine this by enabling a couple debug flags and adding debug statements in the deb-systemd-helper
perl script. On an Ubuntu 16.04 system I found it here: /usr/bin/deb-systemd-helper
.
So repeatedly running the following and adding debug statements got me to the bottom of the problem.
$ sudo DPKG_MAINTSCRIPT_PACKAGE=1 _DEB_SYSTEMD_HELPER_DEBUG=1 deb-systemd-helper enable foo.service
New contributor
It looks like theAlias
line causesdeb-systemd-helper
to create a link to/etc/systemd/system
- which is not necessarily what I want. Can you show what you have inrules
other than%: dh $@ --with-systemd
to get your service auto-enabled and started?
â Guss
yesterday
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
add a comment |Â
up vote
0
down vote
I ran into this issue as well. It turns out that dh_systemd_enable
has certain expectations about the content of a foo.service
file.
You can see this in lines 187-215 of deb-systemd-helper.
In particular, ensuring that the foo.service
file has an [Install]
section and has at least an Alias
field where the alias does NOT equal foo.service
will cause the call to deb-systemd-helper enable
to detect the needed service. If you want the service to be automatically started adding WantedBy=multi-user.target
is also needed.
Below is a lightly modified version of my foo.service
file:
[Unit]
Description=foo service, foos
After=bar.service
Requires=bar.service
[Service]
ExecStart=/path/to/my/script/foo
Restart=always
RestartSec=5
[Install]
Alias=foo
WantedBy=multi-user.target
I was able to determine this by enabling a couple debug flags and adding debug statements in the deb-systemd-helper
perl script. On an Ubuntu 16.04 system I found it here: /usr/bin/deb-systemd-helper
.
So repeatedly running the following and adding debug statements got me to the bottom of the problem.
$ sudo DPKG_MAINTSCRIPT_PACKAGE=1 _DEB_SYSTEMD_HELPER_DEBUG=1 deb-systemd-helper enable foo.service
New contributor
It looks like theAlias
line causesdeb-systemd-helper
to create a link to/etc/systemd/system
- which is not necessarily what I want. Can you show what you have inrules
other than%: dh $@ --with-systemd
to get your service auto-enabled and started?
â Guss
yesterday
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I ran into this issue as well. It turns out that dh_systemd_enable
has certain expectations about the content of a foo.service
file.
You can see this in lines 187-215 of deb-systemd-helper.
In particular, ensuring that the foo.service
file has an [Install]
section and has at least an Alias
field where the alias does NOT equal foo.service
will cause the call to deb-systemd-helper enable
to detect the needed service. If you want the service to be automatically started adding WantedBy=multi-user.target
is also needed.
Below is a lightly modified version of my foo.service
file:
[Unit]
Description=foo service, foos
After=bar.service
Requires=bar.service
[Service]
ExecStart=/path/to/my/script/foo
Restart=always
RestartSec=5
[Install]
Alias=foo
WantedBy=multi-user.target
I was able to determine this by enabling a couple debug flags and adding debug statements in the deb-systemd-helper
perl script. On an Ubuntu 16.04 system I found it here: /usr/bin/deb-systemd-helper
.
So repeatedly running the following and adding debug statements got me to the bottom of the problem.
$ sudo DPKG_MAINTSCRIPT_PACKAGE=1 _DEB_SYSTEMD_HELPER_DEBUG=1 deb-systemd-helper enable foo.service
New contributor
I ran into this issue as well. It turns out that dh_systemd_enable
has certain expectations about the content of a foo.service
file.
You can see this in lines 187-215 of deb-systemd-helper.
In particular, ensuring that the foo.service
file has an [Install]
section and has at least an Alias
field where the alias does NOT equal foo.service
will cause the call to deb-systemd-helper enable
to detect the needed service. If you want the service to be automatically started adding WantedBy=multi-user.target
is also needed.
Below is a lightly modified version of my foo.service
file:
[Unit]
Description=foo service, foos
After=bar.service
Requires=bar.service
[Service]
ExecStart=/path/to/my/script/foo
Restart=always
RestartSec=5
[Install]
Alias=foo
WantedBy=multi-user.target
I was able to determine this by enabling a couple debug flags and adding debug statements in the deb-systemd-helper
perl script. On an Ubuntu 16.04 system I found it here: /usr/bin/deb-systemd-helper
.
So repeatedly running the following and adding debug statements got me to the bottom of the problem.
$ sudo DPKG_MAINTSCRIPT_PACKAGE=1 _DEB_SYSTEMD_HELPER_DEBUG=1 deb-systemd-helper enable foo.service
New contributor
edited 18 mins ago
New contributor
answered yesterday
Gabriel
11
11
New contributor
New contributor
It looks like theAlias
line causesdeb-systemd-helper
to create a link to/etc/systemd/system
- which is not necessarily what I want. Can you show what you have inrules
other than%: dh $@ --with-systemd
to get your service auto-enabled and started?
â Guss
yesterday
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
add a comment |Â
It looks like theAlias
line causesdeb-systemd-helper
to create a link to/etc/systemd/system
- which is not necessarily what I want. Can you show what you have inrules
other than%: dh $@ --with-systemd
to get your service auto-enabled and started?
â Guss
yesterday
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
It looks like the
Alias
line causes deb-systemd-helper
to create a link to /etc/systemd/system
- which is not necessarily what I want. Can you show what you have in rules
other than %: dh $@ --with-systemd
to get your service auto-enabled and started?â Guss
yesterday
It looks like the
Alias
line causes deb-systemd-helper
to create a link to /etc/systemd/system
- which is not necessarily what I want. Can you show what you have in rules
other than %: dh $@ --with-systemd
to get your service auto-enabled and started?â Guss
yesterday
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.
$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g.
$ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>.
$ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
â Gabriel
21 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f274624%2fautomatically-enable-systemd-services-installed-using-deb%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I've worked around the problem by calling
dh_systemd_enable
(to make the service run by default) anddh_systemd_start
(to actually start it after installation) manually from theoverride_dh_auto_install
target inrules
, but I still don't understand why it doesn't get called automatically - as promised in its documentation.â Guss
Apr 6 '16 at 11:51
I haven't worked with
.deb
packages, but I have worked with custom.rpm
packages that I wanted to enable a service for. Withrpm
s there's apost
section, which will just run the commands in it after install is finished. That's where I threw in asystemctl enable
. I assume.deb
has something similar.â Centimane
Jul 5 '17 at 12:58
dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - the
dh_auto_install
step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)â Guss
Jul 5 '17 at 14:05
1
You need 3 things:
rules
to containdh $@ --with systemd
,control
to containBuild-Depends: dh-systemd
,postinst
to contain#DEBHELPER#
and a reasonable current build systemâ Tino
Oct 1 at 13:40