starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

headscale.service location #478

New Issue
Closed
opened 2025-12-29 02:18:41 +01:00 by adam · 10 comments
adam commented 2025-12-29 02:18:41 +01:00
Owner
Copy Link

Originally created by @zoenglinghou on GitHub (Apr 20, 2023).

Bug description
headscale.service should not be installed to /etc/systemd/system

To Reproduce

dpkg -L headscale.deb

Context info
It is my understanding that systemd unit files from a package should be installed to /usr/lib/systemd/system, and would be symlinked to /etc/systemd/system upon systemctl enable. Sometimes the postinst and prerm would handle the service enabling and stopping too.

Originally created by @zoenglinghou on GitHub (Apr 20, 2023). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the bug report in this language. --> **Bug description** `headscale.service` should not be installed to `/etc/systemd/system` <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> **To Reproduce** ```bash dpkg -L headscale.deb ``` <!-- Steps to reproduce the behavior. --> **Context info** It is my understanding that systemd `unit` files from a package should be installed to `/usr/lib/systemd/system`, and would be symlinked to `/etc/systemd/system` upon `systemctl enable`. Sometimes the `postinst` and `prerm` would handle the service enabling and stopping too. <!-- Please add relevant information about your system. For example: - Version of headscale used - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output -->
adam added the bug label 2025-12-29 02:18:41 +01:00
adam closed this issue 2025-12-29 02:18:41 +01:00
adam commented 2025-12-29 02:18:41 +01:00
Author
Owner
Copy Link

@jonathanspw commented on GitHub (Apr 20, 2023):

You are correct on this.

@jonathanspw commented on GitHub (Apr 20, 2023): You are correct on this.
adam commented 2025-12-29 02:18:42 +01:00
Author
Owner
Copy Link

@loprima-l commented on GitHub (Apr 28, 2023):

I guess it depends on the linux version and OS, I'm not so familiar with Linux, did you know how is it on other OSes?

@loprima-l commented on GitHub (Apr 28, 2023): I guess it depends on the linux version and OS, I'm not so familiar with Linux, did you know how is it on other OSes?
adam commented 2025-12-29 02:18:42 +01:00
Author
Owner
Copy Link

@zoenglinghou commented on GitHub (Apr 28, 2023):

I guess it depends on the linux version and OS, I'm not so familiar with Linux, did you know how is it on other OSes?

I know this is the packaging convention on Debian-, RedHat-, and Arch-Families. macOS would use a different init system

@zoenglinghou commented on GitHub (Apr 28, 2023): > I guess it depends on the linux version and OS, I'm not so familiar with Linux, did you know how is it on other OSes? I know this is the packaging convention on Debian-, RedHat-, and Arch-Families. macOS would use a different init system
adam commented 2025-12-29 02:18:43 +01:00
Author
Owner
Copy Link

@jonathanspw commented on GitHub (Apr 28, 2023):

It's standard across systemd-based systems. /usr/lib/systemd is for units from packages. /etc/systemd/system is for custom stuff/non-packaged stuff.

In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.

src: https://www.freedesktop.org/software/systemd/man/systemd.unit.html

tldr: it's all about precedence. Use /usr/lib/systemd to allow users to override things if they desire in a clean way.

@jonathanspw commented on GitHub (Apr 28, 2023): It's standard across systemd-based systems. `/usr/lib/systemd` is for units from packages. `/etc/systemd/system` is for custom stuff/non-packaged stuff. > In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in. src: https://www.freedesktop.org/software/systemd/man/systemd.unit.html tldr: it's all about precedence. Use /usr/lib/systemd to allow users to override things if they desire in a clean way.
adam commented 2025-12-29 02:18:43 +01:00
Author
Owner
Copy Link

@loprima-l commented on GitHub (Apr 28, 2023):

@jonathanspw I think you're already working on the RPM package build, as I'm not familiar with Linux, can you make a pull request for this or at least make the changes on the .rpm ?

@loprima-l commented on GitHub (Apr 28, 2023): @jonathanspw I think you're already working on the RPM package build, as I'm not familiar with Linux, can you make a pull request for this or at least make the changes on the .rpm ?
adam commented 2025-12-29 02:18:43 +01:00
Author
Owner
Copy Link

@jonathanspw commented on GitHub (Apr 28, 2023):

It's already correct in the RPMs. PRd to fix the .debs.

@jonathanspw commented on GitHub (Apr 28, 2023): It's already correct in the RPMs. PRd to fix the `.deb`s.
adam commented 2025-12-29 02:18:43 +01:00
Author
Owner
Copy Link

@loprima-l commented on GitHub (Apr 28, 2023):

Oh, I supposed that the error was everywhere, nice job ^^

@loprima-l commented on GitHub (Apr 28, 2023): Oh, I supposed that the error was everywhere, nice job ^^
adam commented 2025-12-29 02:18:44 +01:00
Author
Owner
Copy Link

@loprima-l commented on GitHub (Apr 28, 2023):

@zoenglinghou You can close your Issue, @jonathanspw Got ya !

@loprima-l commented on GitHub (Apr 28, 2023): @zoenglinghou You can close your Issue, @jonathanspw Got ya !
adam commented 2025-12-29 02:18:44 +01:00
Author
Owner
Copy Link

@jonathanspw commented on GitHub (Apr 28, 2023):

When the PR is merged it will close it automatically :)

@jonathanspw commented on GitHub (Apr 28, 2023): When the PR is merged it will close it automatically :)
adam commented 2025-12-29 02:18:44 +01:00
Author
Owner
Copy Link

@zoenglinghou commented on GitHub (Apr 29, 2023):

Thanks @jonathanspw

@zoenglinghou commented on GitHub (Apr 29, 2023): Thanks @jonathanspw
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#478
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?