[arch-projects] [netcfg] systemd v. initscripts
Hi Jouke, It notice that we have /etc/rc.d/net-profiles, but /usr/lib/systemd/system/netcfg.service. That mostly does not matter, but in order to make people's life easier when converting from initsrcipts to systemd, and in particular if they use the compatibility layer to parse DAEMONS automatically, it would be nice if the rc script and the systemd unit had the same name. Renaming the unit file is probably a bad idea by now, but just adding a symlink net-profiles.service -> netcfg.service should do the trick. What do you think? Tom
On Sat, Aug 4, 2012 at 3:08 PM, Tom Gundersen <teg@jklm.no> wrote:
Hi Jouke,
It notice that we have /etc/rc.d/net-profiles, but /usr/lib/systemd/system/netcfg.service. That mostly does not matter, but in order to make people's life easier when converting from initsrcipts to systemd, and in particular if they use the compatibility layer to parse DAEMONS automatically, it would be nice if the rc script and the systemd unit had the same name. Renaming the unit file is probably a bad idea by now, but just adding a symlink net-profiles.service -> netcfg.service should do the trick.
What do you think?
Tom
I don't think this is urgent enough to justify a new release, but I am willing to take it into the next version. Is there a compatibility layer that makes transition easier with the symlink in place? IIRC the net-profiles name dates back to the time when netcfg was part of initscripts. In fact, I was quite satisfied with the new, simpler naming scheme ;-P. - Jouke
On Mon, Aug 6, 2012 at 4:17 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I don't think this is urgent enough to justify a new release, but I am willing to take it into the next version. Is there a compatibility layer that makes transition easier with the symlink in place? IIRC the net-profiles name dates back to the time when netcfg was part of initscripts. In fact, I was quite satisfied with the new, simpler naming scheme ;-P.
If you have initscripts installed (so you are not on a pure systemd system. Then there is a compatibility layer so that systemd creates wrapper units for all your rc scripts, and starts the rc scripts that you have listed in DAEMONS. This works nicely (IMO), in the way that native systemd services are always preferred to the legacy ones, so as time goes by and more and more packages ship native systemd files, the legacy stuff becomes less and less relevant. However, in order for systemd to know that the native unit file is the same as the legacy rc script, they need to have the same name, or at least there needs to be a symlink in place with the name of the rc script. If this is not the case, then the legacy rc script will be used and the native file will be ignored. There is one last scenario, which is the reason I'd like this added: if you keep your legacy rc daemon enabled in DAEMONS, and you enable the systemd unit file using systemctl, and systemd does not know that they are the same, then it will try to start the same thing twice. This usually fails and people get confused about the warnings (usually one of the instances will stay around, so it is ok). -t
On Mon, Aug 6, 2012 at 4:17 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I don't think this is urgent enough to justify a new release, but I am willing to take it into the next version.
Just in case anyone is following this: the fix is part of the current release in [testing]. -t
On Thu, Aug 9, 2012 at 5:55 PM, Tom Gundersen <teg@jklm.no> wrote:
On Mon, Aug 6, 2012 at 4:17 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I don't think this is urgent enough to justify a new release, but I am willing to take it into the next version.
Just in case anyone is following this: the fix is part of the current release in [testing].
-t
Yeah, my message to the list got bounced because I did not format the title correctly and because of the ongoing vacation I am not spending the usual amount of time on e-mail. - Jouke
participants (2)
-
Jouke Witteveen
-
Tom Gundersen