DA unable to restart services

G

GITK Services

Verified User
Joined
Mar 8, 2004
Messages
37
Location
Lancashire, UK
Attempting to restart a service in DA comes up with the following (ProFTPd in this example):

Shutting down proftpd: [ OK ] Starting proftpd: daemon: not found [ FAILED ]

Any suggestions? Am I missing a link somewhere that's hardcoded? I can see daemon as /usr/sbin/daemon.

Thanks in advance.
 
Has this worked for you before?

(Note that I have no answers for FreeBSD solutions; I'm asking the question only because it might help others to know the answer.)

Jeff
 
GITK Services said:
Attempting to restart a service in DA comes up with the following (ProFTPd in this example):

Shutting down proftpd: [ OK ] Starting proftpd: daemon: not found [ FAILED ]

Any suggestions? Am I missing a link somewhere that's hardcoded? I can see daemon as /usr/sbin/daemon.

Thanks in advance.
Click to expand...

Did you upgrade ProFTP?
 
If you used the DA package of proftpd the path should be correct already.
 
Re: Re: DA unable to restart services

jlasman said:
Has this worked for you before?
Jeff
Click to expand...

Yes, before moving the server / upgrading to FreeBSD 5.4, reinstalling DA normally, and restoring user data.

Senad said:
Did you upgrade ProFTP?
Click to expand...

Nah, this issue isn't specific to ProFTPd, any daemon service has the issue. It can be restarted fine using /usr/local/etc/init.d/* scripts, but not by the control panel.

We did do a server move and migration copying a lot of stuff, and noticed the odd glitch. It appears that DA is attempting to execute "daemon" from somewhere, and I'm not sure where from. Could be a missing link from /usr/bin or something similar?
 
Last edited:
Re: Re: Re: DA unable to restart services

GITK Services said:
YNah, this issue isn't specific to ProFTPd, any daemon service has the issue. It can be restarted fine using /usr/local/etc/init.d/* scripts, but not by the control panel.
Click to expand...

That dir doesnt exist on FreeBSD you are running a falvour of linux or your FreeBSD install is seriously fudged.

The DA start scripts should be located in /usr/local/etc/rc.d on a bsd system.
 
Whoops!

Chrysalis said:
That dir doesnt exist on FreeBSD you are running a falvour of linux or your FreeBSD install is seriously fudged.

The DA start scripts should be located in /usr/local/etc/rc.d on a bsd system.
Click to expand...

Sorry, my fault. It was meant to be /usr/local/etc/rc.d - it was a late late night, and I'd just been working on a Fedora box, so I was probably a tad confused!

Sorry for the confusion.
 
Certainly, although I must stress, the rc.d scripts DO work when invoked from the shell - it's just DA that can't seem to run "daemon".

There's also some duplicates which are non-active - installed from the ports system a while ago.

Code: 
-r-xr-xr-x  1 root  wheel    50 Jul  1 09:54 000.compat4x.sh
-rwxr-x---  1 root  wheel   181 Sep 24 15:11 000.mysql-client.sh
-r-xr-xr-x  1 root  wheel   413 Jul  1 10:09 000.pkgtools.sh
-rwxr-xr-x  1 root  wheel   226 May 10 08:09 boot.sh
-r-xr-xr-x  1 root  wheel   687 Oct 16 16:06 clamav-clamd.sh
-r-xr-xr-x  1 root  wheel   722 Oct 16 16:06 clamav-freshclam.sh
-r-xr-xr-x  1 root  wheel  1066 Oct 16 16:06 clamav-milter.sh
-rwxr-xr-x  1 root  wheel  1132 May 10 08:10 da-popb4smtp
-rwxr-xr-x  1 root  wheel  1428 May 10 08:09 directadmin
-rwxr-xr-x  1 root  wheel  1754 May 11 18:53 exim
-r-xr-xr-x  1 root  wheel  1190 Oct 16 15:56 exim.sh
-rwxr-xr-x  1 root  wheel   908 May 10 08:09 functions
-rwxr-xr-x  1 root  wheel  2972 Sep 24 16:12 httpd
----------  1 root  wheel  1689 Sep 24 15:50 mysql-server.sh
-rwxr-x---  1 root  wheel   717 Sep 24 15:52 mysqld
-r-xr-xr-x  1 root  wheel  1248 Aug  7 07:26 mysqld.orig
-rwxr-xr-x  1 root  wheel    95 May 10 11:04 named
-rwxr-xr-x  1 root  wheel   356 May 10 08:09 pidof
-rwxr-xr-x  1 root  wheel  2054 Aug 27  2003 proftpd
-r-xr-xr-x  1 root  wheel   696 Oct 16 16:07 sa-spamd.sh
lrwxr-xr-x  1 root  wheel    14 May 10 18:14 sshd -> /etc/rc.d/sshd
-rwxr-xr-x  1 root  wheel  3447 May 10 08:09 sshd.old
-r-xr-xr-x  1 root  wheel   392 Jul 25 10:48 sshd.sh.sample
-rwxr-xr-x  1 root  wheel   728 May 10 08:09 startips
-rwxr-xr-x  1 root  wheel   960 Dec 11  2003 vm-pop3d
 
hmm check /usr/local/directadmin/data/admin/services.status and see if proftpd=ON exists. If it does I have no idea what the issue is, if '/usr/local/etc/rc.d/proftpd start' works fine in the shell DA should be able to start it just fine.
 
This issue isn't specific to ProFTPd. Any service DA tries to restart fails with a similar error.

I get the feeling it's looking for it elsewhere to /usr/sbin for daemon, but I'm not certain. To be honest, DA should really be running the init scripts, unless it's something I've missed in there.
 
GITK DA just runs the rc.d scripts. Not the binary direct. So if the rc.d script works in the shell it should work from DA in theory. You can confirm you have the correct licence installed?
 
I was wondering why it would have an issue. There WAS initially a license issue actually, but it was corrected before the install was completed.

All looks kosher though in the license data. Any idea where I'd spot something to do with this?
 
License type is a major contributory issue since it specifies how DA is installed to the server. Looks like to me that license issue you had is causing your problems and I suggest you reinstall DA from the start with the correct license.
 
Shouldn't be though, as I trashed the DA directory (/usr/local/directadmin) before reinstalling, just to be on the safe side.

I've e-mailed DA support to see if they can shed any light.
 
Hello,

We've got daemon on our 5.3 system.
Code: 
freebsd53# which daemon
/usr/sbin/daemon
The easy way out would just be to change all the boot scripts to not use the daemon program, eg, edit /usr/local/etc/rc.d/proftpd, and change:
Code: 
start() {
        echo -n "Starting proftpd: "
        daemon /usr/local/sbin/proftpd
        RETVAL=$?
to
Code: 
start() {
        echo -n "Starting proftpd: "
        /usr/local/sbin/proftpd
        RETVAL=$?
I wouldn't see any issues with doing that.

Alternatively, you'd need to figure out how to install "daemon".. but I'm really not sure where it comes from as we've always had it with default installs.

John
 
You must log in or register to reply here.
Back
Top