Webmin 1.540 still does not support Upstart jobs

I just tested the new Webmin 1.540, and in the Bootup and shutdown module, just like with the previous version, it still does not show/edit most of the services correctly.

All services that use Upstart style configurations are shown as "At boot: no" even though they are started through Upstart.

Trying to stop them results in the warning:

Executing /etc/init.d/mysql stop ..
 
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql stop
 
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) utility, e.g. stop mysql
mysql stop/waiting

Setting "At boot" to "no" has no effect, since the Upstart config file in /etc/init is not modified.

Status: 
Active

Comments

Thanks ronald for the hint!

I tried that patch and modified the "upstart-job" file accordingly, unfortunately still no-go.

MySQL is still listed as "At boot: no" in Webmin, although it does get started through Upstart.

Is there anything else I need to do after patching the file? Can you (or someone) tell me what exactly that patch does and how it is supposed to affect Webmin's behavior concerning Upstart?

Webmin 1.540 should support upstart just fine .. are you running Ubuntu 10.10 there, or 10.04 ?

Also, if you SSH in as root and try to disable an action with a command like insserv -r bind9 , does it report any errors?

It's Ubuntu 10.04 LTS. I'm not touching non-LTS versions for my servers. :)

root@lyra:~# uname -a
Linux lyra 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux

No errors, but some warning, for the requested insserv command:

root@lyra:~# insserv -r bind9
insserv: warning: script 'S02lookup-domain' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (0 6) of script `umountroot' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0) of script `halt' overwrites defaults (empty).
insserv: warning: script 'lookup-domain' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (0 6) of script `umountfs' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `wpa-ifupdown' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `umountnfs.sh' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `sendsigs' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (6) of script `reboot' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `networking' overwrites defaults (empty).

BIND9 does not seem to be started through Upstart though. There's no conf file for it in /etc/init, and the command /etc/init.d/bind9 stop does not issue a warning.

I'm not really sure how this whole Upstart business really works actually and how it plays together with the /etc/init.d thing.

Fact is, e.g. MySQL does get started at boot-up, but Webmin lists it as "At boot: no". Trying to get its status gives:

root@lyra:/etc/init.d# /etc/init.d/mysql status
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql status
 
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status mysql
mysql start/running, process 1046

I did some googling and it seems that Upstart uses a considerably different way of specifying when what is going to start, and also different commands to start/stop.

Conf files in /etc/init determine when to start what. I haven't found a command yet to modify the start behavior, it seems the conf files need to be edited or renamed to disable Upstart jobs.

http://ubuntuforums.org/showpost.php?p=8476712&postcount=4

http://anonir.wordpress.com/2010/08/09/ubuntu-lucid-disable-services-fro...

The old init.d scripts get called from Upstart through the /etc/init/rc.conf job.

So, it would seem, to really support Upstart, Webmin needs to parse the conf files in /etc/init.d and rename them to disable a job. Currently it does not seem to be doing that.

From my tests, upstart still creates the symlinks from /etc/rc*.d/service to /etc/init.d/service , which is what Webmin looks at to determine if an action is started at boot or not.

On your system, what does ls /etc/rc*.d/*mysql* output?

From my tests, upstart still creates the symlinks from /etc/rc*.d/service to /etc/init.d/service

It seems it does not on Ubuntu... All weblinks I found concerning the topic also seem to confirm that.

root@lyra:/etc# ls /etc/rc*.d/*mysql*
ls: cannot access /etc/rc*.d/*mysql*: No such file or directory

Edit: You really need to fix that forum software concerning markup sequences within "code" blocks.

Yeah, those <em>s look a like a Drupal bug. You can avoid this by escaping the * with a \ before it.

As for the symlink issue, I am confused as to why your system behaves different to ours. Can I login to this system myself as root to see what is going wrong?

Yep, certainly. I'll send you a "Remote Login Privileges" request via Virtualmin. Thanks!

The login will be to my experimental VM "lyra". Don't be surprised about some possible "oddities", this system is under heavy experimentation. :) Concerning the Upstart issue though I compared it with my production VM (Ubuntu 10.04 too) and it behaves identical. Both Ubuntus are 64-bit btw, in case that matters.

Should you need access to the production machine "orion", let me know.

Trying the hint about escaping markup now...

/etc/rc*.d/*mysql*

Works with CODE tags.

/etc/rc\*.d/\*mysql\*

Fails with backticks though. ;) Well, no biggie.

Thanks ... logging in to take a look now.

Oops, you are correct .. looks like Webmin will need some fixes to handle upstart better.

I've been saying so for quite a while (way before this report)... Good to see you believe me now. ;)

What's odd is that it does work OK on my test systems! But the current code just assumes that the old-style init behavior is still supported, when it seems that isn't always the case. I will update Webmin to switch completely to upstart's way of doing things, when installed..

Mmh... I think you need to be careful with that.

Not all services on my system are managed (directly) through Upstart. E.g. MySQL is, but BIND isn't.

The latter group is technically and cumulatively fired up by Upstart, through its "RC" job. But the individual "old" services are managed through links /etc/rcN.d directory, like before.

So for the current Ubuntu systems, Webmin would have to support both methods.

Yes, that is how I am implementing it - both classic init.d actions and upstart will be supported.

Two thumbs up then - one for each startup method! :)

Ok, I finally have a fix for this - if you download and install Webmin 1.541 from http://www.webmin.com/devel.html , the Bootup and Shutdown module now fully supports Upstart.

Let us know how it goes ..

Ok, I finally have a fix for this - if you download and install Webmin 1.541 from http://www.webmin.com/devel.html , the Bootup and Shutdown module now fully supports Upstart.

Let us know how it goes ..

Okidoki, will gladly test it on Lyra. Do I fetch the .deb variant and feed it to dpkg? Or is there a "development version repository"?

Easiest method is to just fetch the .deb file and then install it with dpkg -i webmin_1.541_all.deb

Easiest method is to just fetch the .deb file and then install it with dpkg -i webmin_1.541_all.deb

Roger, did that and am testing now. Some first feedback:

  • Both Upstart and "regular" startup actions are shown now.

  • Problem with the "BIND9" service: In the overview list, it is listed as "No" in the "At boot" column, even though in the details screen the radio button is set to "Start at boot time: Yes" (the latter of which is correct).

When I change it to "No", the softlink in /etc/rc5.d is correctly disappears. When I change it back to "Yes", the link is re-created, but with prefix S99 while before it was S02 (that determines the startup order as far as I remember).

  • I cannot start or stop Upstart services from the details screen. The buttons to do that are not there.

  • Example MySQL: Disabling an Upstart job seems to be done by commenting out the "start on" line. But for MySQL, the .conf file looks like this after disabling:

#start on (net-device-up
          and local-filesystems
      and runlevel [2345])
stop on runlevel [016]

I'm assuming ALL of the lines after the "start on" up to but excluding the "stop on" should be commented out, otherwise this will surely give some syntax errors for the unknown "and" directives. :)

Thanks .. I will take a look at these and update the bug.

Ok, I have released Webmin 1.542 which should fix all these issues. Give it a try and let us know how it goes ..

Automatically closed -- issue fixed for 2 weeks with no activity.

Sorry, totally forgot this one! Just tested it with Webmin 1.550.

The two problems pertaining to Upstart are fixed!

The two problems described for BIND still persist. It is shown as "At boot: No" in the overview despite the rc5.d symlink exists. Turning "on boot" off and on re-creates the link with "S99" instead of "S02".

And a new problem now exists:

When I turn "on boot" off and on for an Upstart job, in addition to modifying its /etc/init file, it creates a link in rc*.d. The behavior pertaining to that is a little odd though. When I test this with multiple Upstart jobs, the erroneous symlink for the job I tested just before then disappears, and the link for the new job appears.

It also seems to be fixing the S99 for BIND and changing it to S02 when I turn off/on the next job.

Hope you can figure this odd one out. ;)

Some more stuff:

I'm not sure if this was the case before, but many of the services - e.g. Mailman - in the overview list show "Running now? Unknown".

That probably is due to this:

root@lyra:/var/webmin# /etc/init.d/mailman status
Usage: /etc/init.d/mailman {start|stop|restart|reload|force-reload}

Seems those script do not have a status query option.

How do you determine whether a service is configured to "start at boot" for the overview list? 'cause Mailman also has a startup file /etc/rc5.d/S03mailman present, but is shown as "At boot: no". I tried finding out the commands through Webmin's debug log, but I can't seem to see the commands responsible for that there.

Edit: I compared it against Webmin 1.540, and it seems you have just recently added that "Running now" column, cause it is not present in 1.540. ;)

If an action uses old-style init scripts and the script doesn't accept a status parameter, then Webmin will not be able to determine if it is running and will show "Unknown" .. which is kind of un-avoidable.

As for that BIND issue, do any other /etc/rc/bind9 files exist?

Yeah there are:

./rc2.d/S05bind9
./rc0.d/K02bind9
./rc5.d/S05bind9
./rc3.d/S05bind9
./rc6.d/K02bind9
./rc4.d/S05bind9
./rc1.d/K02bind9

Also, does /etc/init/bind9.conf exist on your system?

Nope, no Upstart job for BIND.

I can send you an SSH login again if you wish to do some tests!

Sure, an SSH login would be really useful!

Thanks ... logging in now

Ok, I see the bug that causes the bind9 script problem, and have fixed in on your system and in my codebase for inclusion in the next Webmin release.

Is there anything else that still isn't working?

To make sure you didn't overlook the reports I posted, lemme repeat:

  • The two problems described for BIND still persist(ed).

    • It is shown as "At boot: No" in the overview despite the rc5.d symlink exists.
    • Turning "on boot" off and on re-creates the link with "S99" instead of "S02".
    • This also applies to e.g. "mailman".
  • When I turn "on boot" off and on for an Upstart job, in addition to modifying its /etc/init file, it creates a link in rc*.d.

    • I tested this with multiple Upstart jobs:
    • The erroneous symlink for the job I tested just before then disappears
    • Instead the link for the new job appears.
    • The erroneous S99 link for BIND is also changed to a correct S02 at this time.

Thanks for the summary - I have made some further changes that should fix these issues now.