Topic awaiting preservation: Java/Perl/Python/C++ - Socket Server Daemon ? (Page 1 of 1)

I'm writing my own TCP socket server, I know there are a lot of free socket servers out there, but it sounded like a fun thing to do. Anyways, I'd like to run it on my web server (Dreamhost : Debian Linux) which supports Java, but not Servlets or JSP.

This means I can run Java apps, but as soon as I terminate my remote session (SSH), the Java app also exits, which means the SSH session needs to be active while the server is running, but I don't want that.

Is there any way to fork off a java process using native Java API's so I can log off the system but keep the java server application running?

Ideally, I'd like something that I could interactively log back into via the shell to administer every now and then (shutdown, restart, aggressively kill latent threads and so forth), something similar to the way you can administer MySQL, but I have no idea how i'd do that or even if that's possible using java. Well, I don't really need anything that complex, just to start and stop the server would be enough for now.

I know it can be done using C++, but I'd rather not go there as my C++ skills are less than dismal. Ideally, I'd want to keep this 100% Java, but I'd be willing to look into Perl or Python solutions as well.

I've come across a C++ wrapper for Java that kinda does what I want, but my limited knowledge in the language confuddled me when it came to understanding the documentation for it.

Any help or suggestions would be greatly appreciated.

The Perl documentation of the fork() function says that killing the parent will kill all the children. So I guess Perl is not a solution to your problem.

I have done what you want in C, but usually a higher level language (like Perl, Java, or Python) tries to protect you from creating zombies and will kill the children when the parent dies.

I don't have much experience with Java or Python so someone else may be able to give you a solution that will work in one of those languages.

-- not necessarily stoned... just beautiful.

Actually usually if you just start a java (or any type of app) with the ampersand after it in an SSH session it won't die with the session.

java yourapp &

should do it.

In java you usually use threads for this kind of thing. What you are generally talking about is creating essentially two apps, your resident deamon application (say like apache or mysql) which creates .pid (process id file) which your admin app (like apachectl or mysqladmin) can then use to access the exposed deamon methods. The most simple of these would be a control app that just gets the pid from the file and then kills that process for shutdown.

You can make these more graceful by using Signal handling

I've actually done a bunch of socket server work. What I did was actually did (and your basic process) was to spawn a listner thread that listens for incoming events, when someone connects you they pawn that off to it's own thread. I also kept another listner open on a different port for a control or admin connection. This is how I would manage the server.



.:[ Never resist a perfect moment ]:.

<edit>

You snuck in there whilst I was formatting my reply to hyper.

Thanks bit, that sounds exactly like what I was looking for!

</edit>

--------------------------------

<edit2>

Although, now I have another question. If the web server itself is restarted, is there any way I can make my socket server restart automagically?

Does the ampersand trick only work for SSH sessions? I couldn't find any documentation on how that works.

Could I run a cronjob or would that infinatly spawn server processes? I supose I could force an exit if the server wasn't able to listen on it's designated port because one process was already running, but that would be needlessly taxing on the server computer. Perhaps get PHP to run an exec if the web based client can't connect?...

Any ideas?

Oh and I'm already using threads. The server listens on a dedicated port, then spawns a new thread to handle each incomming connection. But it's getting the app to stay alive that's the problem, everything else is working, even when using Flash as the client.


</edit2>

--------------------------------

Hmm...

I did a bit of digging around the perl docs and found: http://www.xav.com/perl/lib/Pod/perlipc.html - under the "Complete Dissociation of Child from Parent" heading seems like the ticket, all be it quite complex looking to me as I haven't touched perl in years, but I'd still like to try and find a pure Java solution. Or perhaps there's some method of doing this with a *nix shell script?

I'm not really sure what the right name or terms are for what I'm trying to do, so my googeling efforts seem to be sending me in circles at the moment. Although, Java has something called daemon threads, which do the complete opposite of what I want them to do (Java will exit when the only threads still running are daemon threads). Why sun choose to use that name is beyond me, really throws a spanner in my google efforts.

Oh and seeing as this is being run on a shared server, I don't have root access, just incase you were wondering. I can however compile and run programs. I'm still quite green when it comes to using *nix systems, but I've managed to compile a CGI version of PHP 5 on it so I'm not a complete basket case.

(Edited by Cameron on 08-29-2004 21:36)

Check this out for info on processes in Unix. (according to that you have to use the nohup command so the process stays alive but I've done this with just an ampersand and it worked for me.)

You want the process to restart if the webserver (apache) restarts? Or when the box gets rebooted?

To do it when the box gets rebooted you need to put something in the init files and that probably won't happen on a shared box. There may be a method exposed to you for this but you'll have to check your host docs.



.:[ Never resist a perfect moment ]:.

(Edited by bitdamaged on 08-29-2004 23:02)

I'd say when the box gets rebooted as apache restarting shouldn't effect anything as it's not connecting to anything else at the moment, although it'll hook into a MySQL database at some point, but I'll deal with those issues as they arise.

Although, if there's some way to preidocially check if the server is running, if not then start it, that would suffice. Which is kinda why I was thiking perhaps a cronjob or some command issued from a client if it fails to connect. Dreamhost lets it's users run cronjobs on shared hosting accounts.

Thanks for that link, even after skimming the first page lightbulbs are switching on left right and center for me. You've been super helpfull.

Reading through the PHP manual, it appears as if I can use the exec() command to do what I want. I can simply check the list of currently running processes and if I can't identify the server from the output, then I can simply start it again. If I setup the client to run through this routine whenever it fails to connect to the server everything should work more or less seamlessly given enough delay time between each connection attempt.

I'm starting to see why people like *nix so much.

I'll be a little bit before I get a chance to test this theory fully, but I'll let ya'll know how it pans out.

Thanks again.

Generally you can do this fairly easily with the following command

ps -aux | grep "yourappname"

This should return one line if your app is running and none if it's not. In fact if you do something like this

ps -ef | grep -i "yourappname" | awk '{print $2}'

You should get your process ID by itself (or a list of process lines that match the grep)

If you don't know what this is doing ps -ef should list all processes. You then pipe the results to a grep which will pull out only the lines that contain "yourappname" the -i makes it a case insensative search. The awk line pulls out the second column of those results which should be the process id.

Run the commands with each part to see what happens from a command prompt. Then try it with a php exec to see what happens

ps -ef
ps -ef | grep -i "yourappname" (<-- do this with a process you can see running from the previous command)
ps -ef | grep -i "yourappname" | awk '{print $2}'



.:[ Never resist a perfect moment ]:.

Have a look at the screen documentation - that should allow you to put a process into the background, which will stay there, until you kill it.

...just a little tip about backgrounding a process. If your command/program has output that would usually go to standard out (terminal) you will need to redirect it like so ' yourcommand > output.txt & ' or your proccess will die. Also, if there is a chance of generating an error message you will need to redirect stnderror. This will write it to the same file as standard out- ' yourcommand >& output.txt & '

Thanks for the advice everyone. I really appreciate it.

Bitdamaged: Thanks the examples. I never really knew how pipes worked before, thought they were just some perl related thingy. Looks like I have some reading to do. The problem with computers is, the more you learn about them, the more you realise you know so very little.

TP: I had a peek at screen, but can't see why it offers anything over the usual way someone runs a process in the background? Considering that I'll probably be running a bunch of commands from PHP using exec(), I'll probably end up having a few shell scripts that can hopefully manage everything I need to do. I'll be sure to look into it a little more thought.

Actually, since knowing about "backgrounding" my google searches have been more effective. The problem with the server not being up and running whenever the box is rebooted has often been tackled by the clients running shell scripts to start it up again.

Norm: I kinda picked that up from some of the comments left about the exec() command in the PHP manual. Although how can you tell if something is coming from standard our or from stnderror? Both of them usually output to the console don't they? I'd assume java runtime errors (except for those handled by exceptions) would output to stnderror. Eh, I'm sure I'll figure it out. Looks like I have more reading to do.

Thanks again.