Hi All,

I'm very new to Linux scripting so I'm hoping someone can help me out here. I want to start a java program on startup as user "user". I have 2 questions.

1. Does rc.local run as root? If so is there any way to su - user within the script or to tell rc.local to launch something as user?

2. What is wrong with my script below? It echos fine but won't start the program daemon. (it works fine when I type the command directly into bash)

#! /bin/bash

echo "/usr/bin/java -jar /home/user/mekwars/Server/MekWarsServer.jar & " >/home/user/Desktop/mekwars_startup_log

/usr/bin/java -jar /home/user/mekwars/Server/MekWarsServer.jar & >> /home/user/Desktop/mekwars_startup_log

Permissions are set as
-rwx------ 1 user user 187 Oct 22 17:04 mekwarsStart.sh


Thanks for any help on this, I know it's probably something stupid with the script.

Yes. All SysV init files run as root.

Yes, using su or sudo or a custom launcher (typically a small binary written in C).

I believe it does start the daemon, but the daemon is killed when the session exits.

I would recommend you used something like the following:
The main point you might see is how the command is run. The parentheses start a new subshell. The command is run in the background of that subshell. The setsid makes it run in a new session. All this causes the java process to be detached from the current process entirely.

The cd command is just a guess, just in case the MekWarsServer needs to be started in that directory. Note that the cd command here has no side effects: the script caller will not "see" the cd in any way.

This method means that if you for example run my script in a terminal, then close the terminal, the java process will continue running on the background. However, if you used your script, the java process would get killed (due to hangup signal) as the terminal is closed.

Hi Nominal,

Thanks a million for all your help. The script worked a treat and it's shown me some nice little tricks I'll have to commit to memory.

I have another question or two if you wouldn't mind -

1.The subshell is started under my username and the process is daemonised from that subshell. Does this mean that if were to run the subshell command from within a session that the process would be stopped on logout?

This doesn't apply with rc.local but I'd like to understand more about the inner workings now that I'm running a server.

2. For the sake of security should I create a nologin user called java with no sudo access rights other than the java process and the directory in which it keeps its logs or would this be considered overkill?

I'd be grateful if you could also recommend a site or a book to help me transition from being concerned with "just making things work for now" to understanding what is happening underneath the hood with regard to security, scripting and general administration.

Thanks once again, I do really appreciate the time you've taken to answer my questions on this. I'm marking the thread as solved since my initial questions and problems were solved.

Very useful script

Correct.

No. The subshell and setsid cause the process to be detached. This means it will no longer be related to your session or login at all, and thus will not be killed when you log out.

I recommend creating local (as in plain old UNIX accounts, not in LDAP or AD or any centralized user database) no-login user accounts for each service.

I do not understand what you mean by 'sudo access rights'? If you mean the user would only have access to the java process it runs, and to the log files, then yes: I consider that a good idea. It is certainly not overkill, in my opinion.

For starting Java services, I use a small C program I wrote, user-daemon. You can use it to start the Java service under a specific user account (without using su or sudo), from a normal service script. user-daemon will daemonize the desired service, monitor it for a few seconds to make sure it started up correctly, then exit; it is thus perfectly suited for a service script. It's licensed under GPLv2 or later (same as the Linux kernel) and is therefore open source; feel free to use it if you like. I haven't bothered packaging it, but if you want, I could whip it up into a .rpm or .deb file. To compile and install as it is now, just download user-daemon-1.03.tar.gz and run tar -xzf user-daemon-1.03.tar.gz && cd user-daemon-1.03 && sudo make install . It even has a manpage; see man user-daemon after installing for further info.

Unfortunately, it seems my approach to administration and security is much stricter than most, as I've yet to find book or a site that I could recommend without reservations.

A major change to my own viewpoint occurred when I learned of and moved to using qmail, djbdns and daemontools. Nowadays there are other alternatives to these, but I still find Bernsteins approach elegant.

In general, I've found that keeping systems as modular as possible, and shying away from overarching frameworks, is an excellent long-term strategy. This is nothing new; it is just a variant of the old UNIX philosophy.

Another major change to my approach in system administration occurred when I realized most administrator tasks could be done without su and sudo, by judicious use of local administrator groups, and group access controls. POSIX ACLs (extended access controls) make that even more powerful and versatile. Similarly, most services are better run as independent entities (one or more local users and groups); many access rights problems can be solved simply by arranging proper group memberships. Personally, I only delved into this when cooperating with many other administrators on the same servers; therefore I'm not surprised these features are unknown or at least underutilized by most Linux administrators.

As to scripting, there is really only one thing I'd like to insist on: Learn the full quoting and escaping rules as early and as completely as possible. Apply them always, even when not strictly required. I personally prefer Bash, but I also use POSIX shell (dash in many distributions) for startup and system scripts. I guess this is typical for Linux administrators. Bash and POSIX shell quoting rules are very similar, too. If you use Bash, I recommend you write your scripts so that they support all possible file names, even those with whitespace in them.

But, as I said, I hope others will point you some good resources.