Bug #710

running GMT by a daemon with no home dir

Added by tand about 2 years ago. Updated about 2 years ago.

Status:ClosedStart date:2015-05-28
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:Candidate for next bugfix release
Affected version:4.5.x Platform:Linux

Description

the situation:
the web server (running as daemon:<a local group>) runs a (perl)
script calling various gmt commands (with stderr/out connected
to FIFOs monitored by the cgi program, relaying them to a web page)
the problem:
all gmt commands give out a warning "unable to decide home dir",
Although it seems harmless (all seem to work ok despite the warning),
it is very annoying (and embarrassing as is it relayed to the end-user
the question:
can this checking of "home dir" be avoided and is it really about
a home dir or about the groups of a user? because even though I
defined /tmp as ~daemon, the message still appears!

Associated revisions

Revision 14314
Added by Florian about 2 years ago

Use root directory as home directory if HOME environment not set (Fixes #710).

History

#1 Updated by Paul about 2 years ago

Could you try running your command(s) with --GMT_VERBOSE=quiet and see if that works for you. Most users not running on a server would probably want to be told of such a "fatal" problem.

#2 Updated by Florian about 2 years ago

the problem:
all gmt commands give out a warning "unable to decide home dir",
[...]
the question:
can this checking of "home dir" be avoided and is it really about
a home dir or about the groups of a user?

This warning is about the HOME environment. Is the HOME environment set before the web server or any scripts are invoked as a daemon?

#3 Updated by tand about 2 years ago

Yes, exporting HOME before calling gmt commands solves it. In fact, it does not matter
if the caller has a home or not (I kept getting "unable to determine home dir" even
after setting a home for the daemon), so I guess gmt does not do a passwd enumeration,
it just checks the env variable!

Enyway, now it works as intended; thanks for the (non-dangling) pointer!

#4 Updated by Florian about 2 years ago

Paul, GMT5 would exit if HOME is not set, see gmt_init.c:

 6587   /* Determine HOMEDIR (user home directory) */
 6588
 6589   if ((this_c = getenv ("HOME")) != NULL)
 6590     /* HOME was set */
 6591     GMT->session.HOMEDIR = strdup (this_c);
 6597   else {
 6598     GMT_Report (GMT->parent, GMT_MSG_NORMAL, "Error: Could not determine home directory!\n");
 6599     GMT_exit (GMT, EXIT_FAILURE); return EXIT_FAILURE;
 6600   }

HOME seems to be the only variable GMT5 depends on, although it should run fine without it. Maybe this section can be rewritten to (almost) silently fall back to the root directory instead:

--- gmt_init.c    (revision 14261)
+++ gmt_init.c    (working copy)
@@ -6595,8 +6595,8 @@
         GMT->session.HOMEDIR = strdup (this_c);
 #endif
     else {
-        GMT_Report (GMT->parent, GMT_MSG_NORMAL, "Error: Could not determine home directory!\n");
-        GMT_exit (GMT, EXIT_FAILURE); return EXIT_FAILURE;
+        GMT->session.HOMEDIR = strdup ("/");
+        GMT_Report (GMT->parent, GMT_MSG_VERBOSE, "Warning: HOME environment not set. Using root directory instead.\n");
     }
     DOS_path_fix (GMT->session.HOMEDIR);

#5 Updated by Paul about 2 years ago

  • Status changed from New to Feedback

I agree that exit is a bit harsh and root dir is OK, but how does this play on Windows? Is / acceptable there or are we talking C:/ ?

#6 Updated by Florian about 2 years ago

You cannot assume that C: exists. Could be any drive letter. Safest to me seems to extract the drive letter from GMT->init.runtime_bindir.

#7 Updated by Florian about 2 years ago

If you don't specify the drive letter, Windows will automatically prepend the current drive. I think this is the better solution. Assume for example GMT->init.runtime_bindir points to a read-only network drive.

#8 Updated by Paul about 2 years ago

OK, feel free to implement your patch.
Note the OP specified GMT 4... I can do a similar thing there once your patch is done in 5.

#9 Updated by Florian about 2 years ago

  • Status changed from Feedback to In Progress

Applied in changeset r14314.

#10 Updated by Paul about 2 years ago

  • Status changed from In Progress to Resolved

Thanks, I have made a similar change to GMT 4 (rev 10312) and merged to GMT 5.2 branch as well (r14315).

#11 Updated by Paul about 2 years ago

  • Status changed from Resolved to Closed

Closing this guy.

Also available in: Atom PDF