Cronjob @reboot not working on Directadmin

Richard G

Richard G

Verified User
Joined
Jul 6, 2008
Messages
13,874
Location
Maastricht
On a Centos 5 VPS we had a cronjob running for a user. I'm not sure if we had running DA on that server.
I made it myself and it was something like this (path was different if there was DA on the server):
Code: 
@reboot /home/user/start.sh
Which worked perfectly.

Now I tried the same on a Centos 6 64-bit server with Directadmin like this:
Code: 
@reboot /home/admin/domains/mydomain.nl/public_html/test/start.sh
But this won't work after a reboot, neither is it possible to make a cronjob via the DA interface with @reboot in it.

So at this moment it's fixed by using a workaround via the /etc/crontab but that is not the nicest solution.

It this a bug? Is DA looking at the cronjob but not recognizing the @reboot statement and thus ignoring it?
 
Hello,

While I don't have answers on your questions. I'd still suggest using

/etc/rc.d/rc.local

Just put there a new line:

Code: 
/home/admin/domains/mydomain.nl/public_html/test/start.sh

Of course if you really trust that script and you're sure that it won't be exploited. For security reasons I would just chattr the script immutable, so nobody would ever be able to modify the script except the root user.
 
I can confirm that DA was not coded with the @reboot functionality in mind.
We can consider this a feature request.

John
 
@Zeiter: Thank you, but that is no solution because if I put it in rc.local, the script would be run as root, I want it to be run as admin.
So that's why I used /etc/crontab instead and made a crontab for user admin at reboot. This works, but is not the nicest way.

@John:
That would be very nice if this could be implemented, because it's a standard cronjob option.
 
I'm just wondering... after a reboot the shoutcast server is running from a bash shell script.
So in a ps faux you will see the bash script (start.sh) running and below that the shoutcast server.
Do I try it otherwise, the shoutcast server will run at it's own, but the start.sh script will be in defunct.

I have script which checks every 15 minutes if the server is running, if not it starts the server and exits again (if I'm correct).
I could change to run that to every minute but that is too much.

Is there not a way to do this after a reboot:
1.) cd to the admin public_html directory
2.) start them monitor script once from here as user admin.
3.) exit the script and leave the shoutcast which is started from the script running, without having a defunct bash script?
 
In that case I should start screen from the script, because it must start from reboot.

At the moment the shell script keeps running with the shoutcast server in it.
If this is normal procedure I can leave it this way.

With the @reboot in cronjob I could just start under the admin account with the commandline only.
I guess I can best leave it now as is, until @reboot get's implemented.
Thank you.
 
Last edited:
That's possible to run

Code: 
screen <any_comand_here>

There is no need to write any script.

By the way I don't deal with shoutcast servers... as I have no requests for that. I did some installation and maintenance works for one of the customers of mine, and we used IceCast. I don't recall any issue with starting it as a daemon.

If the @reboot action from cron is not taken on server start, why do you think that implementing of it into Directadmin would solve your issue?
 
I just installed shoutcast on one of the servers to temporarily take over a job of another server which is being moved to another data center soon. On this server Centovacast is running which has shoutcast implemented already and is running also under admin.

If the @reboot action from cron is not taken on server start, why do you think that implementing of it into Directadmin would solve your issue?
Click to expand...
It is taken at server start, but only as root, not under a DA user account. So I wonder why you think that implementing it into Directadmin would not solve the issue?
IMHO users should also be able to have cronjobs started at reboot, which is not possible right now because it's not implemented.
As I stated, it's working at this moment with an @reboot statement in /etc/cronjob.
I fixed it like this, but it's not a good solution. This option should work from a users cronjob too (without the username in it in that case):
Code: 
@reboot admin /home/admin/domains/mydomain.nl/public_html/shout/start.sh

Again, i do -not- want to run shoutcast as root.
That's why I don't see a difference in having a shell script running at boot which start the daemon, or when I call screen from the shell script (both as user), it will have the same effect (bash script keeps running) or am I mistaken?
 
It is taken at server start, but only as root, not under a DA user account. So I wonder why you think that implementing it into Directadmin would not solve the issue?
Click to expand...

This is how I understood your issue, you've a cron task:

Code: 
[root@server]# crontab -u admin -l
@reboot /home/admin/domains/mydomain.nl/public_html/test/start.sh

Right? And it does not get executed on server reboot. If it's true, then it's I'd rather say a system level issue, and how implementing it into directadmin (software level) can solve the issue? I might missing something.

As I stated, it's working at this moment with an @reboot statement in /etc/cronjob.
Click to expand...

I've tested here on my box with:

Code: 
[root@server]# crontab -u admin -l
@reboot touch /tmp/reboot.ADMIN

and done:

Code: 
[root@server]# service crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]

and got in logs (/var/log/cron):

Code: 
Mar  4 18:58:13 vps2 crontab[1108]: (root) LIST (admin)
Mar  4 18:58:17 vps2 crond[1123]: (CRON) STARTUP (1.4.4)
Mar  4 18:58:17 vps2 crond[1123]: (CRON) INFO (running with inotify support)
Mar  4 18:58:17 vps2 crond[1123]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

Thus I'd guess it will will be run at computer's startup


Again, i do -not- want to run shoutcast as root.
Click to expand...

You can always run a command from name of any active user on the box
Code: 
su - username -c 'command'
for example:

Code: 
[root@server]# su - admin -c 'whoami'
admin
[root@server]# whoami
root
[root@server]#

IMHO users should also be able to have cronjobs started at reboot, which is not possible right now because it's not implemented.
Click to expand...

As in my particular case on the servers for shared hosting, we don't allow our customers to run daemons. I'd like to have the feature (if it gets implemented) disabled by default for security reasons.
 
Right? And it does not get executed on server reboot. If it's true, then it's I'd rather say a system level issue, and how implementing it into directadmin (software level) can solve the issue? I might missing something.
Click to expand...
Correct, it does not get executed on server reboot. That is true, but I wonder if it's a system level issue, because on a server with users but without DA, there is no problem running it. And the normal crontab for root execute's it also without a problem.

The test you did, gives the same output on my system in the crontab logfile:
Code: 
Mar  4 13:24:47 server12 crond[2976]: (CRON) STARTUP (1.4.4)
Mar  4 13:24:47 server12 crond[2976]: (CRON) INFO (running with inotify support)
Mar  4 13:24:47 server12 crond[2976]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Indeed, one should presume (as you do) that it would be run at startup.

It looks as if it does after a reboot according to the log:
Code: 
Mar  4 14:20:16 server12 crond[2913]: (CRON) STARTUP (1.4.4)
Mar  4 14:20:16 server12 crond[2913]: (CRON) INFO (running with inotify support)
Mar  4 14:20:16 server12 CROND[2960]: (admin) CMD (/home/admin/domains/mydomain.nl/public_html/shout/start.sh)

But it doesn't, not even when I use the sc_serv executable in the cronjob like this:
Code: 
@reboot /home/admin/domains/mydomain.nl/public_html/shout/sc_serv

As said... on a server without Directadmin, I don't have this problem.
Running from /etc/crontab (like stated) I don't have a problem.

This only occurs on DA server when using @reboot in a user's cronjob.
It could still be a software problem though, but I wouldn't know what could be causing it in that case.

I'd like to have the feature (if it gets implemented) disabled by default for security reasons.
Click to expand...
I agree with that ofcourse.
 
I've just tested it in Directadmin powered VPS (OpenVZ VE), and here is what I've got:

Code: 
Mar  4 21:04:42 server crontab[28139]: (root) LIST (admin)
Mar  4 21:04:44 server crontab[28140]: (root) BEGIN EDIT (admin)
Mar  4 21:04:52 server crontab[28140]: (root) REPLACE (admin)
Mar  4 21:04:52 server crontab[28140]: (root) END EDIT (admin)

So I've added a crontab task:

Code: 
[root@server ~]# crontab -u admin -l
@reboot touch /tmp/reboot.ADMIN

The task was not run on cron restart:

Code: 
Mar  4 21:05:03 server crond[28260]: (CRON) STARTUP (V5.0)
Mar  4 21:05:03 server crond[28260]: (CRON) @reboot jobs will be run at computer's startup. ()
Mar  4 21:05:22 server crontab[29902]: (root) LIST (admin)

So I've rebooted the server:

Code: 
[root@server ~]# last -4
root     pts/0        109.bbb.ccc.ddd    Mon Mar  4 21:06   still logged in
reboot   system boot  2.6.18-308.el5.0 Mon Mar  4 21:06          (00:04)
root     pts/1        109.bbb.ccc.ddd    Mon Mar  4 21:04 - down   (00:01)

And the task was run:

Code: 
Mar  4 21:06:24 server crond[3365]: (CRON) STARTUP (V5.0)
Mar  4 21:06:24 server crond[3370]: (admin) CMD (touch /tmp/reboot.ADMIN)

Here is a file:

Code: 
[root@server ~]# LANG=C stat /tmp/reboot.ADMIN
  File: `/tmp/reboot.ADMIN'
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 3eh/62d Inode: 4202043966  Links: 1
Access: (0644/-rw-r--r--)  Uid: (  502/   admin)   Gid: (  502/   admin)
Access: 2013-03-04 21:06:24.305127581 +0700
Modify: 2013-03-04 21:06:24.305127581 +0700
Change: 2013-03-04 21:06:24.305127581 +0700
[root@server ~]#

The tested box is

Code: 
[root@server ~]# cat /etc/redhat-release
CentOS release 5.9 (Final)
 
Oh great, thank you for testing it!!

I formally had it also once on a VPS too and it worked there too, but I was not sure if DA was running on that VPS so I did not mention that one.
At this moment I have Centos 5.x servers but I can't reboot them, they in production and busy used. The only one which are reasonable free and possible to test were that VPS without DA on which it worked OK (Centos 5.9) and the server I'm trying it on now, where it didn't work.

And that's a Centos 6.3 server 64-bit.
Linux server12.server03.nl 3.2.13-grsec-xxxx-grs-ipv6-64 #1 SMP Thu Mar 29 09:48:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Click to expand...

So it might indeed be a system problem. Maybe Centos 6?
I will try it on another Centos 6 server late this night, which is almost ready for use, maybe I can also do a fast try on a Centos 5 server late this night, if I'm still awake ofcourse.
Thanks for testing!
 
Last edited:
Oke, beat me now because now I'm completely clueless.

When creating a cronjob like your's:
Code: 
@reboot touch /home/admin/admin.REBOOT
Then on all servers I tested with, including the one with the problem, the cronjob is started and the file admin.REBOOT is created after reboot. So it's not a Centos 6.x problem.

So why does it not start binaries or bash scripts? I don't understand.

Edit: Never mind... don't ask me how, but suddenly with the binary it's working as should be... Everything is OK now.
 
Last edited:
You must log in or register to reply here.
Back
Top