[arch-general] about FS#30053 and systemd service/unit file in general
hi. So I was playing with an archlinux guest in vbox to learn a bit about systemd. And I found out that the gpm.service was broken. systemctl enable or systemctl start does not work for gpm.service. I looked for bugs and found FS#30053 https://bugs.archlinux.org/task/30053 I just copied and pasted the feature request from the bug report and added one more line and it worked this time. here it is. [Unit] Description=GPM daemon Requires=getty.target [Service] Type=forking EnvironmentFile=/etc/conf.d/gpm ExecStart=/usr/sbin/gpm $GPM_ARGS [Install] WantedBy=multi-user.target I requested the bug to be reopened and it was denied. That's not the problem. The problem for me is the reasoning behind the denial: I quote "We don't want to be using Arch-specific service files, and anything with /etc/conf.d would be that. If you need to use special options, make a copy of the service in /etc and change it directly. As to the missing [Install] section, I'd open a new report." Systemd is made to boot/init a linux distro. But our distro here is archlinux and we are making archlinux package, right ? I understand we ship unpatched upstream package, but do we want to ship broken package so that they stay untouched ? For me, systemd service/unit file are just meant to be that, tailored to archlinux. Well, I am a newbie systemd user, so if this is required that we customize every broken systemd service to make it work, so be it.
On Mon, Jun 11, 2012 at 10:59 AM, solsTiCe d'Hiver
Systemd is made to boot/init a linux distro. But our distro here is archlinux and we are making archlinux package, right ? I understand we ship unpatched upstream package, but do we want to ship broken package so that they stay untouched ?
The point you are missing is that we want all unit files to one day be shipped upstream, and to use the upstream versions in our package. When this eventually happens we don't want the transition from the "arch version" to the "upstream version" to cause a change in behavior.
For me, systemd service/unit file are just meant to be that, tailored to archlinux.
Why should starting gpm (or any other daemon) on Arch be different than on any other distro? We are really not that special that we need/want to tailor stuff to work with Arch. Traditionally, every distro has had some version of our /etc/conf.d/<pkgname>.conf, but all in different locations and using different formats. This sort of made sense when we had rc scripts, as editing them was not something an admin would want to do, so a mechanism to configure them was needed. However, with systemd service files we want to improve on this situation: We can get rid of the distro-specific and redundant configuration files, and rather ship default service files that work as expected in almost all cases. In the cases that you'd want to change the behavior, it is as simple as copying the file from /usr to /etc and editing it there (or, better: use the daemon's native config file, if available). There might be cases where this does not work and we NEED an EnvironmentFile=, but unless we know this to be the case we should avoid it.
Well, I am a newbie systemd user, his is required that we customize every broken systemd service to make it work, so be it.
What I gathered from your message was that what makes the current service file broken is the missing [Install] section, this should obviously be fixed. Clearly service files should not be "broken" by default, so if there are further issues, they should be fixed too. -t
@tom @rodrigo. Ok. Thank you to make it more clear for me. And I thought the gpm arg declared in /etc/conf.d/gpm was needed. It is not here. But others might need it. Hence the bug (feature request) not opened by me. Yes. The only needed part was the [Install] one So, configuration will be handled inside systemd custom service file ?? @rodrigo: +1 for .include but it does not work if one have to change an already defined directive. But your example is good.
On Mon, Jun 11, 2012 at 12:24 PM, solsTiCe d'Hiver < solstice.dhiver@gmail.com> wrote:
@rodrigo: +1 for .include but it does not work if one have to change an already defined directive.
Yes, that is unfortunate. But systemd is still a WIP, so maybe they will eventually make up something for this kind of problem. I'll be tuned.
On Mon, Jun 11, 2012 at 10:59 AM, solsTiCe d'Hiver < solstice.dhiver@gmail.com> wrote:
For me, systemd service/unit file are just meant to be that, tailored to archlinux.
I think that they talk about the lines
EnvironmentFile=/etc/conf.d/gpm ExecStart=/usr/sbin/gpm $GPM_ARGS The /etc/conf.d/gpm files is used _only_ for givin options to the gmp daemon. In a systemd configuration you usually dont want or need this. Simply have a file /usr/lib/systemd/system/gpm.service with: ExecStart=/usr/sbin/gpm If you need to pass extra arguments you copy it into /etc/systemd/system/pm.service and change the line ExecStart=/usr/sbin/gpm --extra-options And no need for extra /etc/conf.d/* files. Naturally, if you really want you can still use the file with EnvironmentFile=, but that's not the Systemd Way (tm). Personally I would prefer that the package version would have: ExecStart=/usr/sbin/gpm $GPM_ARGS Without even defining the GPM_ARGS variable (or with a sane default). And then we can have in /etc/...: .include /usr/lib/systemd/system/gpm.service [Service] Environment=GPM_ARGS=--extra-options Or even EnvironmentFile=... And no need to keep track of every change in the upstream file. Just my two cents. Regards. -- Rodrigo
participants (3)
-
Rodrigo Rivas
-
solsTiCe d'Hiver
-
Tom Gundersen