Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#4202 bacula start/stop/restart buttons do not work

1.620
open
Jamie Cameron
5
2014-08-16
2013-02-18
Bozonius
No

bacula 5.2.12 on Scientific Linux 6.3 and webmin 1.620.

Bacula webmin start, stop, and restart buttons do not work with webmin 1.620, 1.610, 1.600, 1.590 (and possibly others). These buttons have no effect on the actual status of any of the 3 bacula daemons (bacula-dir, bacula-sd, bacula-fd). It appears that webmin sets the init_mode to upstart because my platform has upstart services, but does not consider the init services also on my platform. bacula is a init service, not upstart.

I can confirm this by running debugging in webmin, as well as eyeballing the code. I tried a variety of different versions of webmin all the way back to 1.590, and this behavior persists in all of them. Strangely, webmin worked correctly for bacula 5.0.0, which is the officially-supported version of bacula on SL/RH/CentOS/etc but after upgrading to bacula 5.2.12, it is not working.

Admittedly, bacula 5.2.12 RPM packaging WAS built locally, not from an officially-supported SL repo. However, there were no bugs or errors during the rpmbuild process, which followed the instructions at http://scientificlinuxforum.org/index.php?showtopic=128 for building SL RPMs. It could be that the 5.0.0 version built for SL was configured or modified somehow for SL, but this is a guess.

I found one item related to this issue of upstart v. init/systemd at https://github.com/webmin/webmin/issues/43, although it is not the exact same problem. However, I think it can be said that this issue is generally an issue with webmin architecture, possibly localized to just the bacula module, but I have not investigated that far.

[One other note, and this may have nothing to do with webmin at all. While debugging for this problem, I noticed some files in /sbin called bacula, a perl script meant to launch all 3 daemons via bacula_ctl_{sd,fd,dir} scripts in the /etc/bacula directory, and binaries called for the names of the 3 daemons. However, an rpm -qf does not reveal where these came from. I have no idea how they got put there. I saved them aside, in case they turn out to be necessary. I do not believe these have any impact on the behavior described, but it is suspicious that they were there and apparently being called by webmin. Incidentally, those bacula_ctl_* scripts appear to be for debugging purposes, not a part of the standard bacula packaging. I do not recall instaling any bacula debugging packages, but perhaps this slips my mind at this time.]

The workaround, of course, is to use the command line. Either the service(1) or direct calls to /etc/init.d/bacula_* work correctly and without incident. System startup and shutdown invoke these properly as well.

This is a kind of hybrid bug/enhancement request because, in theory, platforms should be using one initialization system or another and not mixing them. But reality being what it is, and the long periods of time that *nix* migrations can take for back-support, this request is probably within reason.

Discussion

  • Bozonius
    Bozonius
    2013-02-18

    No other errant or unusual behavior re bacula webmin was observed. This is the only issue encountered.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-19

    Webmin 1.620 should have fixed this issue, by checking for each action if it is an init script, upstart service or whatever.

    The only case in which I can see this failing is if both upstart and init.d actions exist for Bacula. You can test for this by running :

    initctl list | grep bacula

     
  • Bozonius
    Bozonius
    2013-02-19

    I ran the test you suggested, and it returns nothing. Actually, "initctl list" shows a list of maybe 15 or 20 services, none of which are bacula or bacula-related.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-19

    One possible fix for this is to click on the Module Config link in the Bacula module, and set the commands to start and stop bacula to run the appropriate init scripts. If you make that change, does the module behave as expected?

    Also, did you install Bacula from packages provided by Scientific Linux, or from elsewhere?

     
  • Bozonius
    Bozonius
    2013-02-19

    I don't see settings for starting and stopping bacula in the module config link in the bacula module of webmin.

    I explained the installation in the original bug description above.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-19

    Sorry, my previous comment was incorrect.

    What Webmin will try to do when starting Bacula is to look in the "Bacula configuration directory" set on the Module Config page for the "bacula" script. It then runs that like :

    /etc/bacula/bacula start

    to start all the daemons. Does that script exist on your system, and if so does it work OK?

     
  • Bozonius
    Bozonius
    2013-02-21

    It looks like the specfile for at least 2 src rpms I looked at purposely removes the "bacula" script you refer to, along with some others. Therefore, I believe I am building bacula "correctly" in the sense that the bacula src rpm packager(s) intended. It is, of course, not compatible with webmin's needs.

    Incidentally, my module config for bacula shows "/etc/bacula" not "/etc/bacula/bacula" so I am guessing that the script name is hardcoded in webmin.

    Thank you for your continued interest.

     
  • Bozonius
    Bozonius
    2013-02-21

    I can now confirm that the orignial (supported) version of bacula (5.0.0) on SL 6.3 does, in fact, install that bacula script, but not in /etc/bacula. It installs the file to /usr/sbin.

     
  • Bozonius
    Bozonius
    2013-02-21

    Using the 5.0.0 version of bacula from the repos, I have tried to use the start/stop/restart mechanism in webmin but bacula does not start.

    I seem to recall having this problem way back when I first installed webmin for bacula, and I remember somehow coming across a fix for this. I think it might have been someone on the IRC channel or something like that. I /think/ I remember someone telling me I needed to install some package to make this work right.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-21

    So Webmin should try to use /usr/bin/bacula instead of /etc/bacula/bacula , if the latter doesn't exist.

    If you run /usr/bin/bacula start , does it start all the daemons?

     
  • Bozonius
    Bozonius
    2013-02-21

    No, even the 5.0.0 official RPM software does not appear to work either.. As I posted above, I recall having to install some package or another to make this work on CentOS/Scientific Linux. I just do not recall what at this point.

    The point really is that, out-of-the-box, the RPM does not provide the correct configuration.

    (NB: The file gets installed to /usr/sbin, not /usr/bin.)

     
  • Bozonius
    Bozonius
    2013-02-21

    I note that the script called "bacula" calls some other programs which do not exist, at least not in the place indicated in that script. I think that might be the missing package I was thinking of.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-22

    That's unfortunately - if /usr/bin/bacula isn't working, there isn't much Webmin can do.

     
  • Bozonius
    Bozonius
    2013-02-22

    I find myself feeling sort of confused figuring out where responsibilities for each webmin subsystem begin and end.

    On one hand, I sense that the bacula webmin subsystem is supplied by the webmin project, and I would imagine that is true of the other subsystems that webmin currently supports. If that is true, then I assume that the webmin project is aware of peculiarities of each subsystem and handles each accordingly.

    To handle each subsystem accordingly means to me that if there are changes over time in the specific implementation of those various subsystems that webmin would somehow adjust to support them. Webmin is dealing with moving targets all the time.

    One example is a fix you put in a while back to handle the system services subsystem in webmin. You added the ability to handle "hybrid" linux platforms where both init/systemd and upstart were present. This was because of the ever-changing nature of the targets your project provides for.

    If so, it would be consistent for webmin to address the specific manner in which bacula starts, stops, and restarts. These days at least, that is done by calls to either service(1) or directly to /etc/init.d/bacula-{dir,sd,fd}, the former being slightly more portable I think. Otherwise, webmin is now requiring each subsystem to keep its part of webmin up to date, or some arrangement like that, which would be very difficult.

    To the best of my knowledge, the bacula script that webmin currently tries to run is not intended to be part of the standard bacula setup. If that is not the case, then a bug would need to be filed against the bacula project. But judging by the fact that those scripts webmin tries to call are not supported -- intentionally, apparently, as per the current specfile for bacula -- I don't think that the bacula project will want to support this non-standard way of starting and stopping their servers.

    But, as I said to begin with, this division of labor is a bit confusing to me. That probably has to do with the fact that I have not been following the saga of either of these projects for a very long time as I am sure you and the other project's developers have.

    BTW, I think webmin is fabulous, and I am not sure what I would do without it, now that it has crippled my desire to figure out the guts of so many of the subsystems it handles. It seems like there are some things that it can do that are very tedious and error-prone if performed manually or with other tools. So even if I sound confused or incorrect about the issue above, I want you to know that I appreciate your past and continuing support of webmin.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-22

    Both the bacula module and the core of Webmin are written by the same developers, so they should be in sync with each other.

    The problem in this case though is that the bacula module isn't trying to run the init scripts at all - instead it is trying to use the "bacula" command, which in the past has worked. But if that is no longer reliable, we can change Webmin to use init scripts instead.

     
  • Bozonius
    Bozonius
    2013-02-23

    Whether the bacula and core modules were written by the same group or not I would still expect they were in sync to ensure it worked at all. This was never the issue. The issue is whether the bacula module is in sync with the bacula project, and it seems it is not. That is why I was asking if each project supplies its piece of webmin or if the webmin maintainers supplies it. The answer to this is now clear, thank you.

    There is still the matter of supporting the init/systemd v upstart APIs depending on which (or both) systems each platform webmin is running on. Perhaps you could use the same logic you used for that prior bug (see below) to address this issue generally throughout webmin? As various Linux distros migrate to upstart (which seems to be a trend for some of them), webmin will be able to handle these differences without requiring maintenance.

     
  • Jamie Cameron
    Jamie Cameron
    2013-02-24

    Ok, I see what you mean now.
    No, the Bacula module for webmin is not maintained by the same people that maintain Bacula itself, so they can get out of sync.

    Regarding the init scripts, upstart, systemd and init.d should be fully supported by Webmin already - including on systems that use a mix of types.

    In the next release of the Bacula module for webmin, I will add an option to force use of the init scripts, which should address your problem.

     
  • Bozonius
    Bozonius
    2013-02-24

    Why can't webmin automatically detect which of the systems to use? A service will only be in one or the other. Forcing a choice will only lead to later bugs and maintenance should bacula (or any other webmin-supported service) or the Linux platform change which of the systems it uses for the service.