]] Michael Biebl Hi,
> Am 11.05.2014 18:51, schrieb Tollef Fog Heen: > > > > reassign 747743 openssh-server > > thanks > > > > ]] Julian Wollrath > > > >> I have the package openssh-server installed but disabled starting the > >> server > >> daemon via 'update-rc.d ssh disable', since I do not need it running all > >> the > >> time. When I switched to systemd suddenly the ssh service was started > >> despite > >> the fact, that I had disabled it. But I also had kdm only enabled for > >> runlevel > >> 5, systemd recognized that correctly and did not started it in different > >> runlevels. Somehow the detection that ssh was totally disabled failed (or > >> it > >> was not even tried to detect that). The same holds for the bluetooth > >> service, > >> which I also disabled but which got started by systemd nevertheless. > > > > This sounds like a bug in the SSH packaging, so reassigning to > > openssh-server. > > > > Colin, feel free to poke us if there's anything we can help with. (Or > > reassign back if you feel this is a bug in systemd/dh_systemd.) > > Actually, I discussed that with Michael Stapelberg when we worked on the > dh-systemd helper. The problem is, update-rc.d doesn't provide any API > to query if a SysV init script is enabled or not. We filed a bug for > that a while ago without any feedback so far from the sysvinit > maintainers [0]. > So, when adding a native service file, it's not really possible to > mirror the enabled state in a way which works universally and I don't > think there is anything we can do in the dh_systemd helper regarding > that. I'm also not sure if it is fixable manually. Ok, seems like I might have misjudged then. We should do the 98% solution, which is to check /etc/rc[S2].d/S??$basename then, IMO. If somebody comes up with code to do the check for file-rc and other uncommon systems, that's fine, but sysvinit will be the most common one by far. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org