Automatically enable systemd services installed using deb?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite
1












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?










share|improve this question























  • 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 rpms 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






  • 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














up vote
3
down vote

favorite
1












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?










share|improve this question























  • 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 rpms 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






  • 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












up vote
3
down vote

favorite
1









up vote
3
down vote

favorite
1






1





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?










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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 rpms 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






  • 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
















  • 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 rpms 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






  • 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















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 rpms 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 rpms 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










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.






share|improve this answer






















  • 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

















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





share|improve this answer
















  • 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


















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






share|improve this answer










New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • 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











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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






























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.






share|improve this answer






















  • 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














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.






share|improve this answer






















  • 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












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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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. 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
















  • 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















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












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





share|improve this answer
















  • 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















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





share|improve this answer
















  • 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













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





share|improve this answer












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






share|improve this answer












share|improve this answer



share|improve this answer










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, your postinst script may be missing the #DEBHELPER# (See unix.stackexchange.com/questions/423069/…)
    – Alexis Wilke
    Aug 14 at 4:11













  • 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








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











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






share|improve this answer










New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • 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















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






share|improve this answer










New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • 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













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






share|improve this answer










New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









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







share|improve this answer










New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer








edited 18 mins ago





















New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered yesterday









Gabriel

11




11




New contributor




Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Gabriel is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • 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

















  • 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
















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


















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay