[Osirisis]

I run multiple users and have permission set on the work folder to RW for both myself the owner of the folder and the admin group which my girlfriend is a member of. The client ignores the folder permissions when creating work unit files and claims ownership for whoever is logged in at the time. This creates problems when the other person logs in and attempts to run the app. When you examine the files that were created under the other person, the files are RW for the owner (person logged in at time work was created) and R for the group. This causes the application to complain and download new work, wasting all the frames that were created by the other person. I'm using a temporary workaround by having four separate folders (dual processor), two for each person, but have concerns about the work not making it in, in a timely manner. Any input or suggestions would be appreciated. Thanks.

I've also posted this to the bugs thread on yahoo groups for the client. I suppose I could look into an applescript that goes and changes the permissions on all the files upon login. If anyone can assist with this part or point me to where I can learn how to make an applescript that will do this, I would appreciate it. Thanks again for the help.

[Michael A. Peters]

The client ignores the folder permissions when creating work unit files and claims ownership for whoever is logged in at the time.

That's the way it works.
Unless you have a specific user starting folding, then whoever is logged in starts the process and it runs under the permissions of that user and creates files with the permissions of that user.

The best thing to do in your case would be to use the CLI version of folding installed in the home directory of ONE user, and have the crontab of that user start it.

That way it always run under the same permissions.

-=-
I assume you are running the gui version and these other people are starting it when they log in (or you put it in everyone's login items)
That's what it sounds like, and that's just the way unix is.

[Arkham_c]

Cron is only apprpriate for processes that are reoccuring (hourly, daily, weekly, monthly, etc). A long-running process need only be started once, so a simple shellscript that nohup's the application would be a better solution. You can do this either at startup or manually, whichever you prefer.

To start a command-line tool in such a way that it will not terminate when you log out, make a shellscript something like this:

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
#!/bin/sh

nohup /Applications/Folding/folding &gt;/dev/null <font color = blue>2</font>&gt;&<font color = blue>1</font> &

</font>[/code]

Of course, replace the "/Applications/Folding/folding" with the actual path to the command line application.

Then, on the commandline, use <font face = "courier"> chmod +x [scriptName] </font> to make the script executable, then run it with <font face = "courier"> ./[scriptName] </font> (replacing [scriptName] in both statements with the name for which you saved the script).

[Osirisis]

Originally posted by Michael A. Peters:
<STRONG>

That's the way it works.
Unless you have a specific user starting folding, then whoever is logged in starts the process and it runs under the permissions of that user and creates files with the permissions of that user.

The best thing to do in your case would be to use the CLI version of folding installed in the home directory of ONE user, and have the crontab of that user start it.

That way it always run under the same permissions.

-=-
I assume you are running the gui version and these other people are starting it when they log in (or you put it in everyone's login items)
That's what it sounds like, and that's just the way unix is.</STRONG>

Actually I'm running the CLI version twice. Currently looking into building an Applescript that runs at login and changes the permissions prior to the other person running the app. Again the key here is to minimize wasted effort. If you have two separate apps for each person there's no way to know whenthe second person will get back to working on the original unit. These units are unlike RC5. They actually have a time limit on them. That's the key reason I'm attempting to stick with one set of folders.

[Osirisis]

Originally posted by Arkham_c:
<STRONG>Cron is only apprpriate for processes that are reoccuring (hourly, daily, weekly, monthly, etc). A long-running process need only be started once, so a simple shellscript that nohup's the application would be a better solution. You can do this either at startup or manually, whichever you prefer.

To start a command-line tool in such a way that it will not terminate when you log out, make a shellscript something like this:

&lt;BLOCKQUOTE&gt;&lt;font size="1"face="Geneva, Verdana, Arial"&gt;code:&lt;/font&gt;&lt;HR&gt;&lt;pre&gt;& amp;lt;font size=1 face=courier&gt;
#!/bin/sh

nohup /Applications/Folding/folding &gt;/dev/null &lt;font color = blue&gt;2&lt;/font&gt;&gt;&&lt;font color = blue&gt;1&lt;/font&gt; &

&lt;/font&gt;&lt;/pre&gt;&lt;HR&gt;&lt;/BLOCKQUOTE&gt;

Of course, replace the "/Applications/Folding/folding" with the actual path to the command line application.

Then, on the commandline, use &lt;font face = "courier"&gt; chmod +x [scriptName] &lt;/font&gt; to make the script executable, then run it with &lt;font face = "courier"&gt; ./[scriptName] &lt;/font&gt; (replacing [scriptName] in both statements with the name for which you saved the script).</STRONG>

I'm a Unix newbie. This looks great. Two questions. From reading the X software forum I've picked up some of this. I gather the nohup with the null outputs stop the application from kicking up any errors to the screen and have it run with no interface. Am I interpretting this correctly?

Second question would be, is there any way to have the script check and see if another job is running that is calling on the same app, prior to starting it again? This way I can avoid conflicts. I'm looking for an easy way to automate this if I'm going to use cron as the kickoff tool. I suppose I could set up a logoff script to kill it, but the PID varies, doesn't it? Usually there is always someone logged into the machine.

Have to love us newbies, we ask all sorts of complicated questions Appreciate the input. This is a great way for me to learn some scripting that actually does me some good

[reader50]

If security is not a problem, you could check the box to ignore permissions on that partition.

That is, if you trust your girlfriend not to find those files you have hidden.

[Osirisis]

Originally posted by reader50:
<STRONG>If security is not a problem, you could check the box to ignore permissions on that partition.

That is, if you trust your girlfriend not to find those files you have hidden. </STRONG>

Probably worth considering

I just learned about umask from our in house Unix guru. Time to go off and do some research on implementing it during the user profile load. This will solve all sorts of issues and keep the security in place. Just a matter of figuring out how to make it run in X. I don't have a Mac here at work so all I can do is research. Just PCs. Someone has to help keep them running

Another item that may be of interest that he mentioned is considering running these in run level scripts, that way they always kick off during bootup. But that's a bigger issue for a different day. Going to bite off these issues in small chunks. Starting with the umask which is more approachable than figuring out how OSX boots

[Arkham_c]

Originally posted by Osirisis:
<STRONG>

I'm a Unix newbie. This looks great. Two questions. From reading the X software forum I've picked up some of this. I gather the nohup with the null outputs stop the application from kicking up any errors to the screen and have it run with no interface. Am I interpretting this correctly?
</STRONG>

Yes, you have it right. If you want to log the output somewhere, you can do so by substituting the path to a log file instead of the /dev/null path. Try /var/log/folding.log or /Users/&lt;youruser&gt;/folding.log as starting point.

<STRONG>
Second question would be, is there any way to have the script check and see if another job is running that is calling on the same app, prior to starting it again? This way I can avoid conflicts. I'm looking for an easy way to automate this if I'm going to use cron as the kickoff tool. I suppose I could set up a logoff script to kill it, but the PID varies, doesn't it? Usually there is always someone logged into the machine.
</STRONG>

Look back at some of the older RC5 and Ubero threads. It's not hard to do. You basically add a check before you start.

[Shaktai]

Originally posted by Arkham_c:
<STRONG>

Look back at some of the older RC5 and Ubero threads. It's not hard to do. You basically add a check before you start.</STRONG>

Wow, these are some great ideas. Any chance we could get some of them added to the Folding & Ubero pages under optimization?

[reader50]

Originally posted by Shaktai:
<STRONG>Wow, these are some great ideas. Any chance we could get some of them added to the Folding & Ubero pages under optimization?</STRONG>

I try to put everything worthwhile in Optimization / Hiding pages. And yes, I do read all the threads on the subject so as not to miss anything.

Unfortunately, the Ubero pages are going to be a major pain, I'll likely have to read the java developer docs before starting. Perhaps it would be a good idea to run the Ubero client first too.

[Michael A. Peters]

Cron is only apprpriate for processes that are reoccuring (hourly, daily, weekly, monthly, etc). A long-running process need only be started once, so a simple shellscript that nohup's the application would be a better solution. You can do this either at startup or manually, whichever you prefer.

That is not true.

Many daemons that don't need root have traditionally been started by cron in time past.
With many daemons, you want them to restarts if they fail and die.

It is not uncommon to have root's crontab monitoring services that DO need root to start and are started at boot.
Especially in enterprise you don't want to have to restart a service or daemon that dies manually, instead you want it restarted for you when it dies.

Apache, for example, takes care of itself in this manner- it spons several httpd processes and will fork new ones if some die.
But not all daemons do what apache does, and you'll find that especially if the service is critical to operation, that experienced unix sys admins will closely watch that daemon with cron to make sure it is running.

One of the frequent tricks is to simply have cron try to start the daemon once a minute, sending the error message to /dev/null
If the service is running it won't start. If it died, it gets started.

seti@home works that way.

folding doesn't, so you want to put a wrapper script that gives it that functionallity.

-=-
I realzize you know a lot about unix.
but cron is appropriate for far more than just scheduling stuff that is done frequently.
As you work in more and more enterprise unix situations, you will see cron used just the way I describe.

Cron is already running as a daemon.
If you've already got a daemon running that is capable of starting your service and keeping it up then there is no need to start another daemon to do that for you.

[Grozni Majmun]

Originally posted by Arkham_c:
<STRONG>To start a command-line tool in such a way that it will not terminate when you log out, make a shellscript something like this:

#!/bin/sh

nohup /Applications/Folding/folding &gt;/dev/null 2&gt;&1 &

</STRONG>

This is how I have been running it. Most of the time it works fine. I can monitor the progress of the individual wu in Folding/work/logfile_XX.txt and I can monitor the overall progress in Folding/FAHlog.txt. Sometimes I get a problem, though. It runs for a number of frames (sometimes many, sometimes few), but then suddenly stops that and starts a new wu. The logfiles say that it has been sent to the server, but I don't seem to get credit for it. Also, in both logfiles, it says:

- Couldn't get size info for dyn file: work/wudata_07.dyn
[19:42:44] Starting from initial work packet

What is the problem? Am I getting faulty wu's or is it my setup that is wrong? I haven't noticed this happening when I use the GUI app, but I'd like to get this to work. Most of the time it does work, and my wu gets credited and sent, but this is really annoying if it happens with wu's that are 70% done

I'll appreciate any suggestions or ideas. In the meantime, I am running distributed folding.

Edits: Formatting messed up
[ 04-07-2002: Message edited by: Grozni Majmun ]

[ 04-07-2002: Message edited by: Grozni Majmun ]