webadmin-list — Webmin users mailing list

Re: [webmin-l] Usermin crashing

[<ra...@si...>]

On Wed, 7 Jun 2006, linux wrote:

> Hi,
>
> I couldn't find anything in the archives, though I may have used the wrong
> terms.
>
> We have been running webmin and usermin for a couple years without any
> problems until just recently.  This week I've received calls about usermin
> being down, and the only way I've been able to start it up again is to
> restart the server.
>
> Does usermin or webmin have a log file, or can I turn on logging for them?
>
> I did turn on the e-mail notification for services changing states, and that
> works, I received an e-mail earlier about usermin being down.
>
> For restart usermin I've tried:
> Clicking start from the webmin service monitor, also from the usermin
> configuration page.
> /etc/init.d/usermin restart (and start)
> /etc/usermin/start
> And /usr/libexec/usermin/miniserv.pl /etc/usermin/miniserv.conf  (what
> /etc/usermin/start does)
>
> None of them result in usermin running, nor do they report errors (except
> the ones that try to stop usermin, they error because it isn't running to be
> stopped)
>
> Thanks,
> Mike
>
>

   I have occasionally seen usermin consume all available memory, and then 
crash after selected users try to read their mailboxes with usermin.  The 
miniserv.error file (I have it in /var/usermin) showed "out of memory", 
and the miniserv.log showed a user trying to read mail.

   My problem is that I cannot repeat this problem on demand, so I havn't 
been able to determine the root cause.  Does your logfiles show anything 
similar?


rf

Re: [webmin-l] Usermin crashing

[Jamie C. <jca...@we...>]

On 7/Jun/2006 15:42 Mike wrote ..
> > > Hi,
> > > 
> > > I couldn't find anything in the archives, though I may have 
> > used the wrong
> > > terms.
> > > 
> > > We have been running webmin and usermin for a couple years 
> > without any
> > > problems until just recently.  This week I've received 
> > calls about usermin
> > > being down, and the only way I've been able to start it up 
> > again is to
> > > restart the server.
> > > 
> > > Does usermin or webmin have a log file, or can I turn on 
> > logging for them?
> > > 
> > > I did turn on the e-mail notification for services changing 
> > states, and
> > > that
> > > works, I received an e-mail earlier about usermin being down.
> > > 
> > > For restart usermin I've tried:
> > > Clicking start from the webmin service monitor, also from 
> > the usermin
> > > configuration page.
> > > /etc/init.d/usermin restart (and start)
> > > /etc/usermin/start
> > > And /usr/libexec/usermin/miniserv.pl 
> > /etc/usermin/miniserv.conf  (what
> > > /etc/usermin/start does)
> > > 
> > > None of them result in usermin running, nor do they report 
> > errors (except
> > > the ones that try to stop usermin, they error because it 
> > isn't running
> > > to be
> > > stopped)
> > 
> > When Usermin is down like this, is there still a miniserv.pl 
> > process running
> > for it? The problem may be that it is running but 
> > un-responsive somehow..
> > 
> > If so, you could try the command :
> > 
> > /etc/usermin/stop ; /etc/usermin/start
> > 
> > to restart it.
> 
> There is a miniserv.pl for webmin, but not for usermin.
> I have tried the /etc/usermin/stop followed by /etc/usermin/start
> 
> The stop reports failure because the wasn't anything found for its kill
> command.

Some process must still be listening on port 10000. You can find it with
the command :  lsof -i tcp:10000

 - Jamie

Re: [webmin-l] FSdump with command in "Email message subject"

[Jamie C. <jca...@we...>]

On 7/Jun/2006 14:20 Kaiser, Hans wrote ..
<blockquote type=3D"cite">

<blockquote type=3D"CITE">
    <font color=3D"#000000">The hostname should appear in the email messages when some service is detected to be down..=A0 it will say something like :</font><br />
    <br />
    <font color=3D"#000000">Monitor 'Apache webserver' on yourhost.com has detected that the service is down</font><br />
    <br />
</blockquote>
My problem is, that I have no idea there to configure the receiver e-mail of this module. So I cannot determine the content of the email. There to configure the e-mail for the monitor?
</blockquote>Yes - you click on the Scheduled Monitoring button, which will bring up a page for setting the monitoring schedule, target email address and other options.<br /><br />=A0- Jamie<br /><br />

Re: [webmin-l] Usermin crashing

[Mike <li...@mi...>]

> > Hi,
> > 
> > I couldn't find anything in the archives, though I may have 
> used the wrong
> > terms.
> > 
> > We have been running webmin and usermin for a couple years 
> without any
> > problems until just recently.  This week I've received 
> calls about usermin
> > being down, and the only way I've been able to start it up 
> again is to
> > restart the server.
> > 
> > Does usermin or webmin have a log file, or can I turn on 
> logging for them?
> > 
> > I did turn on the e-mail notification for services changing 
> states, and
> > that
> > works, I received an e-mail earlier about usermin being down.
> > 
> > For restart usermin I've tried:
> > Clicking start from the webmin service monitor, also from 
> the usermin
> > configuration page.
> > /etc/init.d/usermin restart (and start)
> > /etc/usermin/start
> > And /usr/libexec/usermin/miniserv.pl 
> /etc/usermin/miniserv.conf  (what
> > /etc/usermin/start does)
> > 
> > None of them result in usermin running, nor do they report 
> errors (except
> > the ones that try to stop usermin, they error because it 
> isn't running
> > to be
> > stopped)
> 
> When Usermin is down like this, is there still a miniserv.pl 
> process running
> for it? The problem may be that it is running but 
> un-responsive somehow..
> 
> If so, you could try the command :
> 
> /etc/usermin/stop ; /etc/usermin/start
> 
> to restart it.

There is a miniserv.pl for webmin, but not for usermin.
I have tried the /etc/usermin/stop followed by /etc/usermin/start

The stop reports failure because the wasn't anything found for its kill
command.

-Mike

Re: [webmin-l] FSdump with command in "Email message subject"

[Kaiser, H. <r_...@gm...>]

> The hostname should appear in the email messages when some service is
> detected to be down..  it will say something like :
> 
> Monitor 'Apache webserver' on yourhost.com has detected that the
> service is down
> 

My problem is, that I have no idea there to configure the receiver
e-mail of this module. So I cannot determine the content of the email.
There to configure the e-mail for the monitor?

Re: [webmin-l] Usermin crashing

[Jamie C. <jca...@we...>]

On 7/Jun/2006 12:40 linux wrote ..
> Hi,
> 
> I couldn't find anything in the archives, though I may have used the wrong
> terms.
> 
> We have been running webmin and usermin for a couple years without any
> problems until just recently.  This week I've received calls about usermin
> being down, and the only way I've been able to start it up again is to
> restart the server.
> 
> Does usermin or webmin have a log file, or can I turn on logging for them?
> 
> I did turn on the e-mail notification for services changing states, and
> that
> works, I received an e-mail earlier about usermin being down.
> 
> For restart usermin I've tried:
> Clicking start from the webmin service monitor, also from the usermin
> configuration page.
> /etc/init.d/usermin restart (and start)
> /etc/usermin/start
> And /usr/libexec/usermin/miniserv.pl /etc/usermin/miniserv.conf  (what
> /etc/usermin/start does)
> 
> None of them result in usermin running, nor do they report errors (except
> the ones that try to stop usermin, they error because it isn't running
> to be
> stopped)

When Usermin is down like this, is there still a miniserv.pl process running
for it? The problem may be that it is running but un-responsive somehow..

If so, you could try the command :

/etc/usermin/stop ; /etc/usermin/start

to restart it.

 - Jamie

[webmin-l] Usermin crashing

[linux <li...@mi...>]

Hi,

I couldn't find anything in the archives, though I may have used the wrong
terms.

We have been running webmin and usermin for a couple years without any
problems until just recently.  This week I've received calls about usermin
being down, and the only way I've been able to start it up again is to
restart the server.

Does usermin or webmin have a log file, or can I turn on logging for them?  

I did turn on the e-mail notification for services changing states, and that
works, I received an e-mail earlier about usermin being down.

For restart usermin I've tried:
Clicking start from the webmin service monitor, also from the usermin
configuration page.
/etc/init.d/usermin restart (and start)
/etc/usermin/start
And /usr/libexec/usermin/miniserv.pl /etc/usermin/miniserv.conf  (what
/etc/usermin/start does)

None of them result in usermin running, nor do they report errors (except
the ones that try to stop usermin, they error because it isn't running to be
stopped)

Thanks,
Mike

Re: [webmin-l] FSdump with command in "Email message subject"

[Jamie C. <jca...@we...>]

On 7/Jun/2006 03:53 Kaiser, Hans wrote ..
<blockquote type=3D"cite">

<blockquote type=3D"CITE">
    <font color=3D"#000000">Wierd ... I am very surprised that they differ, because the same code is used to get both hostnames.</font><br />
    <font color=3D"#000000">How about the hostname that appears in email sent by the System and Server Status module?</font><br />
</blockquote>
I installed it, but I have no idea, there to set my e-mail to figure out the subject<br /><br />
</blockquote>The hostname should appear in the email messages when some service is detected to be down..=A0 it will say something like :<br /><br />Monitor 'Apache webserver' on yourhost.com has detected that the service is down<br /><br />=A0- Jamie<br /><br />

Re: [webmin-l] webmin problem to startup services; further analisys

[Jamie C. <jca...@we...>]

On 7/Jun/2006 03:02 and...@fr... wrote ..
> If I create a new job aaa via webmin, a new file /etc/init.d/aaa is
> created;
> 
> sogeaste01:/etc/init.d # cat aaa
> #!/bin/sh
> ### BEGIN INIT INFO
> # Provides: aaa
> # Required-Start: $network
> # Required-Stop: $network
> # Default-Start: 2 3 5
> # Description: start dummy aaa
> ### END INIT INFO
> 
> case "$1" in
> 'start')
>         /bin/echo "contents of dummyfile made by aaa on start" >
> /tmp/dummyfile
>         ;;
> 'stop')
>         /bin/echo "contents of dummyfile made by aaa on stop" >
> /tmp/dummyfile
>         ;;
> *)
>         echo "Usage: $0 { start | stop }"
>         ;;
> esac
> exit 0
> 
> an absolute link in /etc/init.d/rc3.d directory is created:
> S99aaa a -> /etc/init.d/aaa
> 
> on reboot, the script doesn't start, and no /tmp/dummyfile is created:
> 
> using yast; entering system services runlevel editor, disabling aaa from
> runlevel 2 3 5 and saving; and re-entering and re-enabling aaa in runlevel
> 2 3 5;
> the script /etc/init.d/aaa is not altered at all; into the directory
> /etc/init.d/rc3.d two new links are created:
>  S07aaa -> ../aaa
>  K15aaa -> ../aaa
> 
> on reboot, the script starts and /tmp/dummyfile shows the proper contents
> sogeaste01:/etc/init.d # cat /tmp/dummyfile
> contents of dummyfile made by aaa on start
> 
> other considerations:
> 
> in the init.d directory, the file .depend.start | stop boot  are not
> altered by webmin on aaa process creation;
> 
> on the other side, when the process is disabled and re-enabled by yast,
> these 3 files are altered; the aaa appears in that files;
> 
> cat .depend.start | grep aaa  (before using yast)
> no lines shown
> 
> cat .depend.start | grep aaa (after using yast)
> 
> TARGETS = kbd nfs fbset earlykbd mysql network alsasound resmgr syslog
> earlysyslog amportal webmin apache2 boot.clock postfix running-kernel
> boot.udev cron powersaved dbus haldaemon acpid portmap nfsboot nscd sshd
> slpd xdm gpm aaa atd raw halt pcscd svnserve autoyast SuSEfirewall2_setup
> rpasswdd mdadmd openct random reboot single joystick saslauthd
> rpmconfigcheck
> 
> aaa: network
> 
> SuSEfirewall2_setup: apache2 kbd fbset mysql alsasound network syslog
> amportal random resmgr webmin apache2 running-kernel boot.udev cron
> powersaved acpid nfs portmap nfsboot dbus nscd sshd postfix postfix
> haldaemon earlykbd xdm earlysyslog aaa atd gpm raw slpd slpd pcscd svnserve
> autoyast rpasswdd mdadmd openct joystick saslauthd rpmconfigcheck
> 
> so now aaa appears in 3 lines of .depend.start; the same behaviour in the
> other files depend.stop
> 
> sogeaste01:/etc/init.d # cat .depend.stop | grep aaa (after using yast)
> 
> TARGETS = kbd nfs fbset earlykbd mysql network alsasound resmgr syslog
> earlysyslog amportal webmin apache2 postfix running-kernel boot.udev cron
> powersaved dbus haldaemon acpid portmap nfsboot nscd sshd slpd xdm gpm
> aaa
> atd raw halt pcscd svnserve autoyast SuSEfirewall2_setup rpasswdd mdadmd
> openct random reboot single joystick saslauthd rpmconfigcheck
> 
> network: mysql syslog amportal webmin apache2 nfs portmap nfsboot nscd
> sshd
> postfix aaa slpd autoyast saslauthd
> 
> pcmcia: mysql amportal webmin apache2 nfs portmap nfsboot nscd sshd postfix
> aaa slpd autoyast saslauthd
> 
> hotplug: mysql amportal webmin apache2 nfs portmap nfsboot nscd sshd
> postfix aaa slpd pcscd autoyast saslauthd
> 
> ********************
> >I think that the underlying problem may be the way Webmin creates the
> >init.d script. What does the chkconfig: line at the top of the script
> >contain on your system?
> 
> Sorry for my english, but I didn't understand the question about chkconfig
> line.......

Thanks for the debugging info ..
Actually, what I was really wondering is if the commands :

chkconfig --add aaa
chkconfig add on

when run as root from the command line creates the same symlinks and
.depend file entries as when you use YaST.

 - Jamie
 

Re: [webmin-l] FSdump with command in "Email message subject"

[Kaiser, H. <r_...@gm...>]

> Wierd ... I am very surprised that they differ, because the same code
> is used to get both hostnames.
> How about the hostname that appears in email sent by the System and
> Server Status module?

I installed it, but I have no idea, there to set my e-mail to figure out
the subject

[webmin-l] webmin problem to startup services; further analisys

[<and...@fr...>]

If I create a new job aaa via webmin, a new file /etc/init.d/aaa is
created;

sogeaste01:/etc/init.d # cat aaa
#!/bin/sh
### BEGIN INIT INFO
# Provides: aaa
# Required-Start: $network
# Required-Stop: $network
# Default-Start: 2 3 5
# Description: start dummy aaa
### END INIT INFO

case "$1" in
'start')
        /bin/echo "contents of dummyfile made by aaa on start" >
/tmp/dummyfile
        ;;
'stop')
        /bin/echo "contents of dummyfile made by aaa on stop" >
/tmp/dummyfile
        ;;
*)
        echo "Usage: $0 { start | stop }"
        ;;
esac
exit 0

an absolute link in /etc/init.d/rc3.d directory is created:
S99aaa a -> /etc/init.d/aaa

on reboot, the script doesn't start, and no /tmp/dummyfile is created:

using yast; entering system services runlevel editor, disabling aaa from
runlevel 2 3 5 and saving; and re-entering and re-enabling aaa in runlevel
2 3 5;
the script /etc/init.d/aaa is not altered at all; into the directory
/etc/init.d/rc3.d two new links are created:
 S07aaa -> ../aaa
 K15aaa -> ../aaa

on reboot, the script starts and /tmp/dummyfile shows the proper contents
sogeaste01:/etc/init.d # cat /tmp/dummyfile
contents of dummyfile made by aaa on start

other considerations:

in the init.d directory, the file .depend.start | stop boot  are not
altered by webmin on aaa process creation;

on the other side, when the process is disabled and re-enabled by yast,
these 3 files are altered; the aaa appears in that files;

cat .depend.start | grep aaa  (before using yast)
no lines shown

cat .depend.start | grep aaa (after using yast)

TARGETS = kbd nfs fbset earlykbd mysql network alsasound resmgr syslog
earlysyslog amportal webmin apache2 boot.clock postfix running-kernel
boot.udev cron powersaved dbus haldaemon acpid portmap nfsboot nscd sshd
slpd xdm gpm aaa atd raw halt pcscd svnserve autoyast SuSEfirewall2_setup
rpasswdd mdadmd openct random reboot single joystick saslauthd
rpmconfigcheck

aaa: network

SuSEfirewall2_setup: apache2 kbd fbset mysql alsasound network syslog
amportal random resmgr webmin apache2 running-kernel boot.udev cron
powersaved acpid nfs portmap nfsboot dbus nscd sshd postfix postfix
haldaemon earlykbd xdm earlysyslog aaa atd gpm raw slpd slpd pcscd svnserve
autoyast rpasswdd mdadmd openct joystick saslauthd rpmconfigcheck

so now aaa appears in 3 lines of .depend.start; the same behaviour in the
other files depend.stop

sogeaste01:/etc/init.d # cat .depend.stop | grep aaa (after using yast)

TARGETS = kbd nfs fbset earlykbd mysql network alsasound resmgr syslog
earlysyslog amportal webmin apache2 postfix running-kernel boot.udev cron
powersaved dbus haldaemon acpid portmap nfsboot nscd sshd slpd xdm gpm aaa
atd raw halt pcscd svnserve autoyast SuSEfirewall2_setup rpasswdd mdadmd
openct random reboot single joystick saslauthd rpmconfigcheck

network: mysql syslog amportal webmin apache2 nfs portmap nfsboot nscd sshd
postfix aaa slpd autoyast saslauthd

pcmcia: mysql amportal webmin apache2 nfs portmap nfsboot nscd sshd postfix
aaa slpd autoyast saslauthd

hotplug: mysql amportal webmin apache2 nfs portmap nfsboot nscd sshd
postfix aaa slpd pcscd autoyast saslauthd

********************
>I think that the underlying problem may be the way Webmin creates the
>init.d script. What does the chkconfig: line at the top of the script
>contain on your system?

Sorry for my english, but I didn't understand the question about chkconfig
line.......

Do you want to know which is the first line of the chkconfig perl script ?
The first lines of /sbin/chkconfig are:
#!/usr/bin/perl

use strict;
use Getopt::Long;
use File::Temp 'tempfile';

my $initdir = '/etc/init.d';
my $inetddir = '/etc/inetd.d';
my $xinetddir = '/etc/xinetd.d';

my %to_d = (
  '0' => 'rc0.d', '1' => 'rc1.d', '2' => 'rc2.d', '3' => 'rc3.d',
  '4' => 'rc4.d', '5' => 'rc5.d', 'S' => 'rcS.d', 'B' => 'boot.d'
);

# which files to skip in $initdir
my %skips_rc = map {$_ => 1} qw {rc rx skeleton powerfail boot halt reboot
single boot.local halt.lo
cal};

.......727 lines total


thanks in advance,

Andrea


Chi ricevesse questa mail per errore e' gentilmente pregato di cancellarla.

Visitate il sito http://www.frameweb.it

Re: [webmin-l] FSdump with command in "Email message subject"

[Jamie C. <jca...@we...>]

On 7/Jun/2006 00:12 Kaiser, Hans wrote ..
<blockquote type=3D"cite">

<blockquote type=3D"CITE">
    <font color=3D"#000000">Ok .. how about the hostname that appears on the main page of Webmin when you login?</font><br />
</blockquote>
Also manni.<br />
<br />
</blockquote>Wierd ... I am very surprised that they differ, because the same code is used to get both hostnames.<br />How about the hostname that appears in email sent by the System and Server Status module?<br /><br />=A0- Jamie<br /><br />

Re: [webmin-l] FSdump with command in "Email message subject"

[Kaiser, H. <r_...@gm...>]

> Ok .. how about the hostname that appears on the main page of Webmin
> when you login?

Also manni.

Re: [webmin-l] problem with bootup and shutdown action

[Kris D. <kd...@vi...>]

and...@fr... wrote:
> No, the directory is correct : /etc/init.d/rc3.d

*blink* *roll eyes*

Just what we need;  another SysV variant.  :/

[snip]
> if I look at the directory /etc/init.d/rc3.d i see
> 
> sogeaste01:/etc/init.d/rc3.d # dir | grep amp
> lrwxrwxrwx   1 root root   11 Jun  6 18:06 K15amportal -> ../amportal
> lrwxrwxrwx   1 root root   11 Jun  6 18:06 S07amportal -> ../amportal

*blink*  Bizarre.  I've *never* seen a system with both "start" (Snn) 
and "kill/stop" (Knn) links in a single rc?.d directory.

> sogeaste01:/etc/init.d/rc3.d # dir | grep my
> lrwxrwxrwx   1 root root    8 Jun  6 18:06 S12mysql -> ../mysql
> 
> so now the numbers are "correct", no more 99; and also the link bacame
> relative; If I reboot the server the job amportal at last starts.

Completely Wild-Assed Guess:  SuSE has added another level of 
indirection somewhere (init scripts actually in /etc/init.d/init.d 
maybe?), and its init system ignores any init script not actually in 
that directory.

That doesn't entirely explain the failure of Webmin to create "proper" 
entries;  I've got a number of systems with absolute syslinks in rc?.d 
directories and the service they refer to works fine.

> So my problem is solved, thanks to you who suggested to use a "System
> dependant" tool to adjust runlevel;
> 
> but If now I use webmin to create a new bootup and shutdown action, let's
> say aaa, again:
> 
> sogeaste01:/etc/init.d/rc3.d # dir /etc/init.d/rc3.d | grep aaa
> lrwxrwxrwx   1 root root   15 Jun  6 18:13 S99aaa -> /etc/init.d/aaa
> 
> absolute link and 99 again...

What about the other rc?.d directories?

I tried a test on my server (White Box 3), and Webmin created a "proper" 
initscript (including the bare minimum entries for chkconfig - the 
shell-level init system tool used by RedHat and most of its close 
derivatives) and all of the proper symlinks (probably by using chkconfig).

I didn't reboot, but I've *NEVER* seen a system service fail to start 
(or even throw up an error) if the symlinks were in place.

-kgd

Re: [webmin-l] FSdump with command in "Email message subject"

[Jamie C. <jca...@we...>]

On 6/Jun/2006 07:51 Kaiser, Hans wrote ..
<blockquote type=3D"cite">

<blockquote type=3D"CITE">
    <font color=3D"#000000">Do you get the same output if you run the 'hostname' command in Webmin's Command Shell module?</font><br />
</blockquote>
Hello Jamie, with the bash and the webmin command shell I get in both environments 'manni' as the hostname.
</blockquote>Ok .. how about the hostname that appears on the main page of Webmin when you login?<br /><br />=A0- Jamie<br /><br />

Re: [webmin-l] bind module records deletion

[<ax...@ax...>]

Thanks alot. I will turn off confirmation as my main server is Gentoo and=
 I
wont be able to do anything with the dev version.

Thanks again

Jamie Cameron (jca...@we...) wrote:
>
> On 6/Jun/2006 04:57 ax...@ax... wrote ..
> > Hi
> >
> > Am I correct in saying that it isnt possible to delete records via we=
bmin
> > currently because of a bug?
> >
> > I cannot delete records as root or any other users and have to do thi=
s
> > manually. The error I receive when trying to delete is
> >
> > "Failed to delete records : None selected"
>
> This is a bug in Webmin 1.270, which only happens when deleting multipl=
e
> records with delete confirmation enabled. To fix it, you can either upg=
rade
> to the latest development version, or turn off confirmation on the Modu=
le
> Config page.
>
>  - Jamie
>
>
>
> -
> Forwarded by the Webmin mailing list at web...@li...=
.net
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>

Re: [webmin-l] bind module records deletion

[Jamie C. <jca...@we...>]

On 6/Jun/2006 04:57 ax...@ax... wrote ..
> Hi
> 
> Am I correct in saying that it isnt possible to delete records via webmin
> currently because of a bug?
> 
> I cannot delete records as root or any other users and have to do this
> manually. The error I receive when trying to delete is
> 
> "Failed to delete records : None selected"

This is a bug in Webmin 1.270, which only happens when deleting multiple
records with delete confirmation enabled. To fix it, you can either upgrade
to the latest development version, or turn off confirmation on the Module
Config page.

 - Jamie

Re: [webmin-l] next version

[Jamie C. <jca...@we...>]

On 6/Jun/2006 04:48 ax...@ax... wrote ..
> Hi
> 
> Do we have a rough estimate of when the next version is going to be released?

I plan to release in a week or two.
If you can't wait that long, a pre-release version with pretty much the same
features in available from http://www.webmin.com/devel.html

 - Jamie

Re: [webmin-l] problem with bootup and shutdown action

[Jamie C. <jca...@we...>]

On 6/Jun/2006 03:27 and...@fr... wrote ..
> If I add a new action, a new file is added to my /etc/init.d directory.
> 
> If I put that job on startup at boot time, a link to that file is created
> in the (on example) /etc/init.d/rc3.d
> 
> If I reboot the box, the job doesn't start.

I suspect that the use of the runlevel 3 link is the problem here..

> I noticed 4 things about that job
> 
> 1) the link is absolute, not relative; almost all are link to ../jobname;
> the new one is linked to /etc/init.d/jobname

That won't cause any problems .. as long as the link points to the right file,
it will work.

> 2) the name is S99jobname, instead of a lower number (last used is, on
> example S15jobname, so in principle S16jobname should be created (I
> think....)

Generally, all user-created actions should have high priorities like 99.
The low priorities like 15 are usually for criticial system-related scripts
which must run first.

> 3) on older systems  I saw two links ; SxxJob Name and KyyJobName; here
> I
> see only S99JobName

The K script is run when the system shuts down. However, for most servers
it is not necessary.

> 4) If I add a new job, and also put that in startup automatic, another
> S99NewJobName link is created (again absolute link)
> 
> I am using Webmin 1.270-1.noarch.rpm, just upgraded to the last fix;
> My operating system is Suse Linux 10.0,  kernel 2.6.13-15.10-default

I think that the underlying problem may be the way Webmin creates the
init.d script. What does the chkconfig: line at the top of the script
contain on your system?

 - Jamie

Re: [webmin-l] problem with bootup and shutdown action

[<and...@fr...>]

VGhhbmtzIGZvciBhbnN3ZXJzOw0KDQpObywgdGhlIGRpcmVjdG9yeSBpcyBjb3JyZWN0IDogL2V0
Yy9pbml0LmQvcmMzLmQNCg0KV2VibWluIGFsd2F5cyBwbGF5ZWQgd2VsbCB3aXRoIFN1c2UgaW4g
dGhlIHBhc3Q7IElmIEkgZGVsZXRlLCBvbiBleGFtcGxlLA0KdGhlIG15c3FsIHNlcnZlciBzdGFy
dHVwIHNjcmlwdCwgd2hpY2ggaGFzIGEgUyBhbmQgSyBlbnRyeQ0KKGZvciBlbnRlcmluZyBhbmQg
bGVhdmluZyBydW5sZXZlbCkgYW5kIHRoZW4gcmVjcmVhdGUgaXQsIG9ubHkgUzk5bXlzcWwgaXMN
CmNyZWF0ZWQuDQpUaGUgc2NyaXB0IGlzIGFjdHVhbGx5IE5PVCBleGVjdXRlZCBhZnRlciByZWJv
b3RpbmcuDQoNCkkgdGhpbmsgdGhhdCBpdCBjb3VsZCBiZSBhIHByb2JsZW0gb2Ygd2VibWluLCBw
ZXJoYXBzIGxvb2tpbmcgYXQgc29tZQ0KY29ycnVwdGVkIGZpbGUuDQoNClN1c2UgaGFzIGEgU3lz
dGVtIHNlcnZpY2VzIHJ1bmxldmVsIGVkaXRvciwgdW5kZXIgeWFzdCwgdG8gbWFuYWdlIHRoZQ0K
c2NyaXB0czsNCg0KYW1wb3J0YWwgYW5kIGFwYWNoZTIgc2hvdWwgYmUgdGhlIHNhbWU6DQoNCnZp
YSB3ZWJtaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN
CiAgfC0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICANCiAgfCBbIF0gIHwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgfC0tLS0tLXwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgIGFtcG9ydGFsICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg
ICAgICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF2dmlhIEFzdGVy
aXNrIHNlcnZlciBlIEZPUCBzZXJ2ZXIgdmlhICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGFtcG9ydGFsIHNjcmlwdCAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg
fC0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICANCiAgfCBbIF0gIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgfC0tLS0tLXwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgIGFwYWNoZTIgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg
ICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0YXJ0IHRoZSBodHRw
ZCBkYWVtb24gQXBhY2hlIDIgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN
Cg0KdmlhIHlhc3QNCg0KIIFTZXJ2aWNlICAgICAgICAgICAgICAgICCBUnVubmluZ4FCgTCBMYEy
gTOBNYE2gVOBRGVzY3JpcHRpb24NCogNCiCBYW1wb3J0YWwgICAgICAgICAgICAgICAggU5vICAg
ICAgICAgICCBIIEggSCBIIEggSCBIIEggUF2dmlhIEFzdGVyaXNrDQpzZXJ2ZXIgZSBGT1ANCiCB
YXBhY2hlMiAgICAgICAgICAgICAgICCBWWVzICAgICAgICAggSCBIIEggTKBM4E1gSCBIIFBcGFj
aGUyIGh0dHBkDQoNCmFzIHlvdSBjYW4gc2VlLCB5YXN0IGtub3dzIHRoYXQgYXBhY2hlIHdpbGwg
c3RhcnQgYXQgcnVubGV2ZWwgMiwzIDUgYW5kDQphbXBvcnRhbCB3aWxsIG5vdCBzdGFydCBhdCBh
bnkgcnVubGV2ZWw7DQpidXQgIHdlYm1pbiBUSElOSyB0aGF0IGJvdGggc2hvdWxkIHN0YXJ0Ljsg
YWZ0ZXIgc2F2aW5nIGNvbmZpZ3VyYXRpb24sIG5vDQpjaGFuZ2VzIGRvbmU6DQoNCiCBU2Vydmlj
ZSAgICAgICAgICAgICAgICAggVJ1bm5pbmeBQoEwgTGBMoEzgTWBNoFTgURlc2NyaXB0aW9uDQqI
DQoggWFtcG9ydGFsICAgICAgICAgICAgICAgIIFObyAgICAggSCBIIEggTKBM4E1gSCBIIFBdnZp
YSBBc3RlcmlzayBzZXJ2ZXIgZQ0KRk9QIHNlcnZlcoENCiCBYXBhY2hlMiAgICAgICAgICAgICAg
ICAggVllcyAgICCBIIEggSCBMoEzgTWBIIEggUFwYWNoZTIgaHR0cGQNCoENCg0Kc28gbm93IGFs
c28gU3lzdGVtIHNlcnZpY2VzIFRISU5LIHRoYXQgYW1wb3J0YWwgc2hvdWxkIHN0YXJ0Ow0KaWYg
SSBsb29rIGF0IHRoZSBkaXJlY3RvcnkgL2V0Yy9pbml0LmQvcmMzLmQgaSBzZWUNCg0Kc29nZWFz
dGUwMTovZXRjL2luaXQuZC9yYzMuZCAjIGRpciB8IGdyZXAgYW1wDQpscnd4cnd4cnd4ICAgMSBy
b290IHJvb3QgICAxMSBKdW4gIDYgMTg6MDYgSzE1YW1wb3J0YWwgLT4gLi4vYW1wb3J0YWwNCmxy
d3hyd3hyd3ggICAxIHJvb3Qgcm9vdCAgIDExIEp1biAgNiAxODowNiBTMDdhbXBvcnRhbCAtPiAu
Li9hbXBvcnRhbA0KDQpzb2dlYXN0ZTAxOi9ldGMvaW5pdC5kL3JjMy5kICMgZGlyIHwgZ3JlcCBt
eQ0KbHJ3eHJ3eHJ3eCAgIDEgcm9vdCByb290ICAgIDggSnVuICA2IDE4OjA2IFMxMm15c3FsIC0+
IC4uL215c3FsDQoNCnNvIG5vdyB0aGUgbnVtYmVycyBhcmUgImNvcnJlY3QiLCBubyBtb3JlIDk5
OyBhbmQgYWxzbyB0aGUgbGluayBiYWNhbWUNCnJlbGF0aXZlOyBJZiBJIHJlYm9vdCB0aGUgc2Vy
dmVyIHRoZSBqb2IgYW1wb3J0YWwgYXQgbGFzdCBzdGFydHMuDQoNClNvIG15IHByb2JsZW0gaXMg
c29sdmVkLCB0aGFua3MgdG8geW91IHdobyBzdWdnZXN0ZWQgdG8gdXNlIGEgIlN5c3RlbQ0KZGVw
ZW5kYW50IiB0b29sIHRvIGFkanVzdCBydW5sZXZlbDsNCg0KYnV0IElmIG5vdyBJIHVzZSB3ZWJt
aW4gdG8gY3JlYXRlIGEgbmV3IGJvb3R1cCBhbmQgc2h1dGRvd24gYWN0aW9uLCBsZXQncw0Kc2F5
IGFhYSwgYWdhaW46DQoNCnNvZ2Vhc3RlMDE6L2V0Yy9pbml0LmQvcmMzLmQgIyBkaXIgL2V0Yy9p
bml0LmQvcmMzLmQgfCBncmVwIGFhYQ0KbHJ3eHJ3eHJ3eCAgIDEgcm9vdCByb290ICAgMTUgSnVu
ICA2IDE4OjEzIFM5OWFhYSAtPiAvZXRjL2luaXQuZC9hYWENCg0KYWJzb2x1dGUgbGluayBhbmQg
OTkgYWdhaW4uLi4NCg0KU28gc29tZXRoaW5nIGlzIG5vdCBPSyBpbiBteSB3ZWJtaW4uLi4uLi4u
Li4uLi4uLi4uDQoNCnRoYW5rcyBhZ2FpbiwNCg0KQW5kcmVhDQoNCg0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICANCiAgICAgICAgICAgICBLcmlzIERldWdhdSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDxrZGV1Z2F1QHZpYW5ldC5j
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg
ICAgYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBUbyANCiAgICAgICAgICAgICBTZW50IGJ5OiAgICAgICAgICAgICAgICAgIFdlYm1pbiB1
c2VycyBsaXN0ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIHdlYmFkbWluLWxpc3Qt
Ym91ICAgICAgICAgPHdlYmFkbWluLWxpc3RAbGlzdHMuc291cmNlZm9yZ2UubmUgDQogICAgICAg
ICAgICAgbmNlc0BsaXN0cy5zb3VyY2UgICAgICAgICB0PiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCiAgICAgICAgICAgICBmb3JnZS5uZXQgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNjIA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgU3ViamVjdCANCiAgICAgICAgICAgICAwNi8wNi8yMDA2IDE3LjAzICAgICAgICAgIFJl
OiBbd2VibWluLWxdIHByb2JsZW0gd2l0aCBib290dXAgIA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgYW5kIHNodXRkb3duIGFjdGlvbiAgICAgICAgICAgICAgICAgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICBQbGVhc2UgcmVzcG9uZCB0byAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIFdlYm1p
biB1c2VycyBsaXN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQogICAgICAgICAgICAgPHdlYmFkbWluLWxpc3RAbGkgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICBzdHMuc291cmNlZm9yZ2UubiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg
ICAgICBldD4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQphbmRy
ZWEubGFuemFAZnJhbWV3ZWIuaXQgd3JvdGU6DQo+IElmIEkgYWRkIGEgbmV3IGFjdGlvbiwgYSBu
ZXcgZmlsZSBpcyBhZGRlZCB0byBteSAvZXRjL2luaXQuZCBkaXJlY3RvcnkuDQo+DQo+IElmIEkg
cHV0IHRoYXQgam9iIG9uIHN0YXJ0dXAgYXQgYm9vdCB0aW1lLCBhIGxpbmsgdG8gdGhhdCBmaWxl
IGlzIGNyZWF0ZWQNCj4gaW4gdGhlIChvbiBleGFtcGxlKSAvZXRjL2luaXQuZC9yYzMuZA0KDQpV
bW1tLi4uICBJIGRvbid0IGtub3cgb2YgYW55IFN5c1Ytc3R5bGUgaW5pdCBzeXN0ZW0gdGhhdCB1
c2VzIGENCmRpcmVjdG9yeSBsaWtlIHRoYXQuICBZb3UgcHJvYmFibHkgbWVhbiAvZXRjL3JjLmQv
cmMzLmQgb3IgL2V0Yy9yYzMuZC4NCihVbmxlc3MgdGhpcyBpcyBhIFN1U0UtaXNtLikNCg0KSG93
ZXZlciwgV2VibWluIHNob3VsZCBiZSBicmlnaHQgZW5vdWdoIHRvIHJlY29nbml6ZSB0aGUgdmFy
aWFudCBhbmQgcHV0DQp0aGUgYXBwcm9wcmlhdGUgc3ltbGlua3MgaW4gcGxhY2UuDQoNCj4gSWYg
SSByZWJvb3QgdGhlIGJveCwgdGhlIGpvYiBkb2Vzbid0IHN0YXJ0Lg0KPg0KPiBJIG5vdGljZWQg
NCB0aGluZ3MgYWJvdXQgdGhhdCBqb2INCj4NCj4gMSkgdGhlIGxpbmsgaXMgYWJzb2x1dGUsIG5v
dCByZWxhdGl2ZTsgYWxtb3N0IGFsbCBhcmUgbGluayB0byAuLi9qb2JuYW1lOw0KPiB0aGUgbmV3
IG9uZSBpcyBsaW5rZWQgdG8gL2V0Yy9pbml0LmQvam9ibmFtZQ0KDQpTaG91bGRuJ3QgYmUgYW4g
aXNzdWUuDQoNCj4gMikgdGhlIG5hbWUgaXMgUzk5am9ibmFtZSwgaW5zdGVhZCBvZiBhIGxvd2Vy
IG51bWJlciAobGFzdCB1c2VkIGlzLCBvbg0KPiBleGFtcGxlIFMxNWpvYm5hbWUsIHNvIGluIHBy
aW5jaXBsZSBTMTZqb2JuYW1lIHNob3VsZCBiZSBjcmVhdGVkIChJDQo+IHRoaW5rLi4uLikNCg0K
VGhlIG51bWJlcnMgaW5kaWNhdGUgdGhlIG9yZGVyIGRhZW1vbnMgc3RhcnQgdXAgaW4sIG5vdCB0
aGUgb3JkZXIgdGhleQ0Kd2VyZSBjcmVhdGVkIGluLiAgRmlndXJpbmcgb3V0IHdoYXQgb3JkZXIg
dG8gc3RhcnQgdmFyaW91cyBzZXJ2aWNlcyBpbg0KaXMgYSBiaXQgb2YgYW4gYXJ0OyAgbW9zdCAi
bG9jYWwiIHNlcnZpY2VzIGFyZSBzdGFydGVkIGxhc3QgdW5sZXNzIHRoZXkNCk1VU1Qgc3RhcnQg
YmVmb3JlIHNvbWV0aGluZyBlbHNlLg0KDQo+IDMpIG9uIG9sZGVyIHN5c3RlbXMgIEkgc2F3IHR3
byBsaW5rcyA7IFN4eEpvYiBOYW1lIGFuZCBLeXlKb2JOYW1lOyBoZXJlIEkNCj4gc2VlIG9ubHkg
Uzk5Sm9iTmFtZQ0KDQpUaGUgZGV0YWlscyBvbiB0aGlzIHdpbGwgdmFyeTsgIHN0cmljdGx5IHNw
ZWFraW5nIHRoZXJlIHNob3VsZCBiZSBPTkUNCnN5bWxpbmsgdG8gdGhlIGluaXQgc2NyaXB0IGlu
IGVhY2ggcmM/LmQgZGlyZWN0b3J5IC0gdHlwaWNhbGx5IFNubg0KKHN0YXJ0dXApIGluIHJjMy5k
LCByYzQuZCwgYW5kIHJjNS5kIChhbmQgcmMyLmQgb24gRGViaWFuKTsgIEtubiAoa2lsbA0Kb3Ig
c2h1dGRvd24pIGluIHJjMC5kIGFuZCByYzYuZC4gICpNb3N0KiBzZXJ2aWNlcyB3aWxsIGhhdmUg
YSBLbm4gbGluaw0KaW4gcmMxLmQgYXMgd2VsbCwgYnV0IGEgZmV3IGNyaXRpY2FsIHRoaW5ncyB3
aWxsIGhhdmUgU25uLg0KDQpHb29nbGUgInN5c3YgaW5pdCIgZm9yIG1vcmUgZGV0YWlscyBvbiBo
b3cgdGhlIHdob2xlIHRoaW5nIGZpdHMgdG9nZXRoZXIuDQoNCj4gNCkgSWYgSSBhZGQgYSBuZXcg
am9iLCBhbmQgYWxzbyBwdXQgdGhhdCBpbiBzdGFydHVwIGF1dG9tYXRpYywgYW5vdGhlcg0KPiBT
OTlOZXdKb2JOYW1lIGxpbmsgaXMgY3JlYXRlZCAoYWdhaW4gYWJzb2x1dGUgbGluaykNCj4NCj4g
SSBhbSB1c2luZyBXZWJtaW4gMS4yNzAtMS5ub2FyY2gucnBtLCBqdXN0IHVwZ3JhZGVkIHRvIHRo
ZSBsYXN0IGZpeDsNCj4gTXkgb3BlcmF0aW5nIHN5c3RlbSBpcyBTdXNlIExpbnV4IDEwLjAsICBr
ZXJuZWwgMi42LjEzLTE1LjEwLWRlZmF1bHQNCg0KV2hlbiB5b3UgcmVib290LCBkbyB5b3Ugc2Vl
IGFueSBleHBlY3RlZCBvdXRwdXQgZnJvbSB5b3VyIG5ldyBqb2I/ICBNb3N0DQppbml0IHNjcmlw
dHMgcHJlc2VudCBvdXRwdXQgb2Ygc29tZSBraW5kIGluZGljYXRpbmcgcm91Z2hseSB3aGF0IHRo
ZXkncmUNCmRvaW5nLCBhbnkgZXJyb3JzLCBhbmQgYSBmaW5hbCAiT0svRkFJTCIgaW5kaWNhdG9y
Lg0KDQpXaGF0IHRvb2xzIGRvZXMgU3VTRSBwcm92aWRlIGZvciBtYW5pcHVsYXRpbmcgc3lzdGVt
IHN0YXJ0dXAgYW5kDQpzaHV0ZG93biB0YXNrcyBvciBqb2JzPyAgV2hhdCBkbyB0aGV5IHNheSBh
Ym91dCB0aGUgaW5pdCBzY3JpcHQgYW5kDQpzeW1saW5rIFdlYm1pbiBpbnN0YWxsZWQ/ICBJSVJD
IFN1U0UgaGFzIGEgZmV3IGF1dG9tYXRlZCB0b29scyB0aGF0DQptZWRkbGUgd2l0aCB0aGluZ3Mg
dGhleSByZWFsbHkgc2hvdWxkbid0IChsaWtlLCBvaCwgc2F5LCB0aGlyZC1wYXJ0eQ0KY2hhbmdl
cyB0byB0aGUgaW5pdCBzeXN0ZW0pLiAgQ2hlY2sgZnJvbSBhIHNoZWxsIGFuZCBzZWUgaWYgeW91
ciBjdXN0b20NCnN0YXJ0dXAgam9icyBhcmUgc3RpbGwgdGhlcmUuDQoNCi1rZ2QNCg0KDQotDQpG
b3J3YXJkZWQgYnkgdGhlIFdlYm1pbiBtYWlsaW5nIGxpc3QgYXQgd2ViYWRtaW4tbGlzdEBsaXN0
cy5zb3VyY2Vmb3JnZS5uZXQNClRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9tIHRoaXMgbGlzdCwgZ28g
dG8NCiBodHRwOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3dlYmFkbWlu
LWxpc3Q=

Re: [webmin-l] problem with bootup and shutdown action

[Kris D. <kd...@vi...>]

and...@fr... wrote:
> If I add a new action, a new file is added to my /etc/init.d directory.
> 
> If I put that job on startup at boot time, a link to that file is created
> in the (on example) /etc/init.d/rc3.d

Ummm...  I don't know of any SysV-style init system that uses a 
directory like that.  You probably mean /etc/rc.d/rc3.d or /etc/rc3.d. 
(Unless this is a SuSE-ism.)

However, Webmin should be bright enough to recognize the variant and put 
the appropriate symlinks in place.

> If I reboot the box, the job doesn't start.
> 
> I noticed 4 things about that job
> 
> 1) the link is absolute, not relative; almost all are link to ../jobname;
> the new one is linked to /etc/init.d/jobname

Shouldn't be an issue.

> 2) the name is S99jobname, instead of a lower number (last used is, on
> example S15jobname, so in principle S16jobname should be created (I
> think....)

The numbers indicate the order daemons start up in, not the order they 
were created in.  Figuring out what order to start various services in 
is a bit of an art;  most "local" services are started last unless they 
MUST start before something else.

> 3) on older systems  I saw two links ; SxxJob Name and KyyJobName; here I
> see only S99JobName

The details on this will vary;  strictly speaking there should be ONE 
symlink to the init script in each rc?.d directory - typically Snn 
(startup) in rc3.d, rc4.d, and rc5.d (and rc2.d on Debian);  Knn (kill 
or shutdown) in rc0.d and rc6.d.  *Most* services will have a Knn link 
in rc1.d as well, but a few critical things will have Snn.

Google "sysv init" for more details on how the whole thing fits together.

> 4) If I add a new job, and also put that in startup automatic, another
> S99NewJobName link is created (again absolute link)
> 
> I am using Webmin 1.270-1.noarch.rpm, just upgraded to the last fix;
> My operating system is Suse Linux 10.0,  kernel 2.6.13-15.10-default

When you reboot, do you see any expected output from your new job?  Most 
init scripts present output of some kind indicating roughly what they're 
doing, any errors, and a final "OK/FAIL" indicator.

What tools does SuSE provide for manipulating system startup and 
shutdown tasks or jobs?  What do they say about the init script and 
symlink Webmin installed?  IIRC SuSE has a few automated tools that 
meddle with things they really shouldn't (like, oh, say, third-party 
changes to the init system).  Check from a shell and see if your custom 
startup jobs are still there.

-kgd

Re: [webmin-l] bind module records deletion

[Obantec S. <su...@ob...>]

----- Original Message ----- 
From: <ax...@ax...>
To: "Webmin users list" <web...@li...>
Sent: Tuesday, June 06, 2006 11:39 AM
Subject: Re: [webmin-l] bind module records deletion


> Thanks
>
> Can you delete any records in the zone? Not the zone itself, but a record,
for
> example an MX or an A record?
>
> I am running bind 9.3.2
>
> Obantec Support (su...@ob...) wrote:
> >
> > ----- Original Message -----
> > From: <ax...@ax...>
> > To: <web...@li...>
> > Sent: Tuesday, June 06, 2006 10:57 AM
> > Subject: [webmin-l] bind module records deletion
> >
> >
> > > Hi
> > >
> > > Am I correct in saying that it isnt possible to delete records via
webmin
> > > currently because of a bug?
> > >
> > > I cannot delete records as root or any other users and have to do this
> > > manually. The error I receive when trying to delete is
> > >
> > > "Failed to delete records : None selected"
> > >
> > > Thanks Again
> > >
> > >
> > >
> > > -
> > > Forwarded by the Webmin mailing list at
> > web...@li...
> > > To remove yourself from this list, go to
> > > http://lists.sourceforge.net/lists/listinfo/webadmin-list
> > >
> > >
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Anti-Virus.
> > > Version: 7.1.394 / Virus Database: 268.8.2/356 - Release Date:
05/06/2006
> > >
> > >
> > Hi
> >
> > i am using 1.270 and bind 9.2.5 and just selected a domain and it
deleted
> > fine.
> >
> > Mark
> >
> >
> >
> > -
> > Forwarded by the Webmin mailing list at
web...@li...
> > To remove yourself from this list, go to
> > http://lists.sourceforge.net/lists/listinfo/webadmin-list
> >
>
>
>
> -
> Forwarded by the Webmin mailing list at
web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>
>
>
> -- 
Hi

yes i just deleted an A record in a zone with no problems.

Mark

Re: [webmin-l] FSdump with command in "Email message subject"

[Kaiser, H. <r_...@gm...>]

> Do you get the same output if you run the 'hostname' command in
> Webmin's Command Shell module?

Hello Jamie, with the bash and the webmin command shell I get in both
environments 'manni' as the hostname.

Re: [webmin-l] bind module records deletion

[<ax...@ax...>]

Thanks

Can you delete any records in the zone? Not the zone itself, but a record=
, for
example an MX or an A record?

I am running bind 9.3.2

Obantec Support (su...@ob...) wrote:
>
> ----- Original Message -----
> From: <ax...@ax...>
> To: <web...@li...>
> Sent: Tuesday, June 06, 2006 10:57 AM
> Subject: [webmin-l] bind module records deletion
>
>
> > Hi
> >
> > Am I correct in saying that it isnt possible to delete records via we=
bmin
> > currently because of a bug?
> >
> > I cannot delete records as root or any other users and have to do thi=
s
> > manually. The error I receive when trying to delete is
> >
> > "Failed to delete records : None selected"
> >
> > Thanks Again
> >
> >
> >
> > -
> > Forwarded by the Webmin mailing list at
> web...@li...
> > To remove yourself from this list, go to
> > http://lists.sourceforge.net/lists/listinfo/webadmin-list
> >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.1.394 / Virus Database: 268.8.2/356 - Release Date: 05/06/=
2006
> >
> >
> Hi
>
> i am using 1.270 and bind 9.2.5 and just selected a domain and it delet=
ed
> fine.
>
> Mark
>
>
>
> -
> Forwarded by the Webmin mailing list at web...@li...=
.net
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>

Re: [webmin-l] bind module records deletion

[Obantec S. <su...@ob...>]

----- Original Message ----- 
From: <ax...@ax...>
To: <web...@li...>
Sent: Tuesday, June 06, 2006 10:57 AM
Subject: [webmin-l] bind module records deletion


> Hi
>
> Am I correct in saying that it isnt possible to delete records via webmin
> currently because of a bug?
>
> I cannot delete records as root or any other users and have to do this
> manually. The error I receive when trying to delete is
>
> "Failed to delete records : None selected"
>
> Thanks Again
>
>
>
> -
> Forwarded by the Webmin mailing list at
web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.1.394 / Virus Database: 268.8.2/356 - Release Date: 05/06/2006
>
>
Hi

i am using 1.270 and bind 9.2.5 and just selected a domain and it deleted
fine.

Mark