systemctl just redirects to chkconfig I think.  Does using chkconfig to disable the service work?  (chkconfig proftpd off)  chkconfig was recently updated, so something could be wrong there.

CC: (none) => luigiwalser

(In reply to David Walser from comment #1)
> systemctl just redirects to chkconfig I think.

Well, systemctl status will show that it is not enabled before reboot.
Testing with smb, reboot showed it disabled and running. :(

>  Does using chkconfig to disable the service work?  (chkconfig proftpd off)

Not going to bother to check. Reboot just hangs and I have to power cycle the system.

Cheap workaround is to wrap systemd server/daemon management in a wrapper to 
   systemctl stop $service
   systemctl disable $service
   chkconfig --del $service

>  chkconfig was recently updated, so something could be wrong there.

I do not think so. I had been seeing disabled services reactivated all though alpha1 but had not done any research to see what was causing it until now.

My WAG is systemd dropped a patch, again. Just like the 1 minute+ shutdown service timeout has come back to haunt us.  :(

I suspect this is something upstream too. Dunno what tho', but I confirm it's happening for me too.

Status: NEW => ASSIGNED
Assignee: bugsquad => mageia

OK, so it seems chkconfig support is now conditional and as I don't add it as a build requires, support wasn't included. I've now added an explicit --enable-chkconfig. 

Sadly this still sucks a bit it seems. Missing out the .service suffix will will still give rubbish feedback to the user on enable and disable (no feedback at all on disable!), so it definitely needs polishing, but if you include the .service suffix it does redirect properly.

I'm tempted to close this but I would like to check back and actually fix the feedback problem (and .service suffix mismatch between native units) before doing so.

(In reply to Colin Guthrie from comment #4)

> Sadly this still sucks a bit it seems. Missing out the .service suffix will
> will still give rubbish feedback to the user on enable and disable (no
> feedback at all on disable!), so it definitely needs polishing, but if you
> include the .service suffix it does redirect properly.

I am going to have to assume you mean with your latest systemd release.

I am a little confused as to where you are wanting the .service.
I know that the newer releases of systemd did not require .service and should be a reasonable default. I.E. No dot in service name argument, automagically add .service inside the code.

> I'm tempted to close this but I would like to check back and actually fix
> the feedback problem (and .service suffix mismatch between native units)
> before doing so.

And this is where I get confused. I have a disable_servers script.
I supply the service name, script appends .service to systemd calls, but does not supply it to chkconfig. Am I going to have to supply .system to chkconfig

Snippet of code I have been using since systemd came out.
      case $_cmd in
	disable)
	  echo "disabling $_serv - $_comment"
	  if [ $_use_systemd -eq 0 ] ; then
	    chkconfig --del "$_serv"
	  else
	    chkconfig --del "$_serv"           # kludge added for 11191 bug
	    systemctl disable ${_serv}.service
	  fi
#	  for _d in 0 1 2 3 4 5 6 7 ; do
#	    /bin/rm -f /etc/rc.d/rc${_d}.d/???${_serv}
#	  done
	;;

Sorry, I'll try and explain better.

With the latest build, you can use systemctl enable/disable with sysvinit scripts again.

Sadly, it's not perfect, e.g.:

"systemctl enable native-unit.service" and "systemctl enable native-unit" are equivalent and both work.

However, "systemctl enable sysvinit.service" and systemctl enable sysvinit" do not both work. The former works, but the latter does not. IMO this needs to be fixed so that native and non-native stuff behaves the same.

So for the avoidance of doubt, chkconfig command should never need a ".service" suffix.

Hope that helps.

This was fixed some time back.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED