And why does the cron task for the root account not get removed when the SD! schedule is deleted?
|
Yes, this is something we've not heard of. Scheduling doesn't really do anything that might lock a volume.
Try running something like: Code:
sudo lsof | grep "The-Volume-Name" |
I believe it does when you quit SD.
|
75-94-82-80:~ george$ sudo lsof | grep "The-Volume-Name"
WARNING: Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your typing when using sudo. Type "man sudo" for more information. To proceed, enter your password, or type Ctrl-C to abort. Password: 75-94-82-80:~ george$ So nothing came up. I'm still not out at my server site, but rather did this on my laptop, but I would think that it would have listed processes associated with my bootup drive, no? ("Macintosh HD") Any other ideas, or syntax, or a GUI utility? -- <SeinfeldParaphrase> These (Unix) pretzels are making me thirsty! </SeinfeldParaphrase> |
>> And why does the cron task for the root account not get removed when the SD! schedule is deleted?
> I believe it does when you quit SD. I'll repeat the exercise when I go back out to the sever site, then report back here, but I vividly recall quitting, SD!, restarting, and having to download CronniX to inspect root's crontab, and having to delete the task. |
Quote:
My preferred lsof invocation is sudo lsof /path/to/volume/root. For the boot volume this would be sudo lsof / (which will probably print out something from every process on the system!). For most other non-boot volumes it looks like sudo lsof /Volumes/mountedVolumeName. If the volume name has spaces or special characters in it, it will need to be quoted (try putting single quotes around it, which will work as long as the volume name does not have any single quotes in it; or just use the shell's filename completion by typing enough characters to disambiguate the name and then hit TAB, it will automatically escape any special characters for you). You can test it out by creating a little sparse image (or using any disk image you might have laying around). Mount the image and open a Finder window to the volume itself or some folder in it. Then run the lsof command. You should see an entry for Finder displayed. |
Good advice from Chris... although the problem here wasn't that the boot volume couldn't be ejected (that's pretty obvious).
Rather, you need to actually substitute your volume name for "The-Volume-Name". |
Ahh, yes. I missed that interpretation. I thought maybe gmachen was testing out the lsof | grep … command using the boot volume name on the laptop as a "trial run" before getting back to the server. But the copy-and-paste of the Terminal output could have been verbatim (not a "sanitized" version) meaning the grep was searching for a made-up volume name.
|
Quote:
Quote:
If so, I'd be academically curious as to what's the difference. Thanks! |
I'm pretty sure that running with "sudo"ed root permissions but from a login session as another user won't set your Home and other items to that user's account for graphical apps.
|
Quote:
- Not sure what is meant by "won't set your Home and other items to that user's account for graphical apps." You mean setting permissions correctly? - But in any event, it may be moot: Remember, we're not talking about actually running a backup from a sudo-launched SD!; we're only so launching SD! to set-up the *schedule*, then quitting, and overnight letting the schedule run the backup as root while the login window is up with no accounts open. Will solely setting the schedule under SD! launched via sudo work? Thanks! (When we get all this ironed-out, maybe it could go in the official FAQ for server administrators.) |
No, I don't think it will, as I said.
|
Dave Nanian obviously is preoccupied with this week's stellar release of SD! 2.5, yet to his credit still finds time to work the forums as best he can, bless his heart! Although he understandably doesn't have time for extended technical tomes on the complexities of Unix.
So I'm wondering whether there are any other Unix experts out there who can explain the - what to me - are very surprising putative differences between doing things in sudo as opposed to formally being logged-in as root, which arise from the security needs by network administrators to clone Mac OS X Server drives while logged-out. I'm academically curious as to why: - If the SD! scheduling (only!) is done under sudo while logged-in to an admin account, instead of while logged-in to the root account, it "won't set your Home and other items to that user's account for graphical apps." Does this mean it won't set permissions correctly? I really don't understand: What difference does it make what account the clone is done from if SD! is making, well, a clone, after all? I would think that all account assignment settings already had been made when things originally were installed. What am I missing? I'm really surprised by this! When I launch other apps under sudo, they seem to think & act like they're in the root account: - Such apps' plist preferences go into the root account's Library/Preferences folder. - With Finder launched as root, moving something to the Trash goes to the root account's Trash folder. - Etc., etc. I trust you get the idea. I just need to understand the rationale behind some of this Unix stuff, even if I haven't been through the some seven years experience I'm told it takes to really get a handle on Unix. I'd like to think that our utilities' GUI shells on top of Unix put the power of Unix also in the hands of the slightly less technically sophisticated. Thanks! |
If that's the case, then it might work (as I said, which is why I don't "think" it'll work). It's worth a try: it's just not something I've tested, since this general configuration, which it might work (run as root), isn't something we encourage...
|
All times are GMT -4. The time now is 06:06 AM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.