Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Win32 Daemon @INC

by CleverHanz (Novice)
on Jan 07, 2008 at 19:42 UTC ( #660916=perlquestion: print w/replies, xml ) Need Help??

CleverHanz has asked for the wisdom of the Perl Monks concerning the following question:

I am having trouble getting a perl script to run as a service under certain specific situations. I have the service set up and running, but I am calling a perl module from a remote server.

I have added a line to put the directory for the server into the @INC array. Problem is, I would like to have the path be a mapped drive and not a UNC path, but when I change the value :

push @INC, "\\\\<server>\\<share>\\<dir>";

to something like :

push @INC, "L:\\<dir>";

The service will not start.

Is it a known issue with Win32 Daemon that it does not recognize or use mapped shares?

I know the script works perfectly with the UNC path, but if I change the UNC to the mapped drive the service will no longer start.

Replies are listed 'Best First'.
Re: Win32 Daemon @INC
by sundialsvc4 (Abbot) on Jan 07, 2008 at 21:26 UTC

    It is my understanding that Windows services now run in a substantially different environment from login sessions, especially on Vista® where they (for instance) no longer have any direct access to the console.

    It is therefore entirely possible – would not surprise me in the slightest – if “drive letter mapping” did not exist at all. Services are now intentionally placed “more than an arm's length away from” the world of interactive users and from anything that those users might be able to control or influence. (After all these years, Microsoft finally got the message!)

    There are many reasons to prefer UNCs. A UNC-path is self describing, whereas a path that uses a “mapped drive letter” is dependent on something that it neither specifies nor controls:   that the drive-letter is not only mapped, but mapped “correctly.” (Whatever that means.)

    Finally, pay very careful attention to the user-id under which the service runs. It should be (in my opinion) a dedicated user-id, chosen for the purpose, which does not allow direct logins but which can only be used by a service. Naturally, that user must have the right to have (read-only) access to the appropriate UNC share.

    (Again for “hacker prevention” reasons, that service-userid should not have read/write access to that share: what it does not require, it should not have, nor be able (by any means whatsoever) to get.

      Thanks for the help. this is most likely the reason I am having this problem. I have the service set up to run as the user with read/write access to the share/drive.

      I also understand that the UNC path has it's merits. My problem is that we use a lot of different automated jobs here, and the IT/Server people occassionall move things around. If I use drive letters in the code then I don't have to change every script running on a given server every time a share is moved to a new machine or changed. I just need to change the mapped drive. I suppose I will just need to mark down this special case and make sure someone remembers it next time the server changes. thanks
Re: Win32 Daemon @INC
by jbert (Priest) on Jan 07, 2008 at 21:11 UTC
    Windows services don't get the same environment as the user who the service is running as would get if they logged in.

    For example, the per-user environment variables aren't set. I assume the same is true of drive mappings for that user.

    You might have luck executing a "NET USE" from your script prior to accessing the drive letter, but that's really no different from using the UNC path directly.

    There may be an invocation which allows services to see this sort of setting - perhaps someone else could chime in if so.

      Actually, unless nothing else has been specified, the service will run as the system user, and the system user does not even have the permissions to access network resources, be they mapped or unmapped.

      The solution is usually to run the service as another user than the default.

Re: Win32 Daemon @INC
by Errto (Vicar) on Jan 07, 2008 at 22:41 UTC

    I've faced a similar issue. The above posters are probably right in that the mapped drive doesn't exist. In fact, even if you have a mapped drive in your default profile, you are currently logged in as that user, starting the service as that user, and have the service configured to run as that user, it still won't work. One solution I've used is to create a scheduled task like so:

    at 17:40 /interactive net use L: \\servername\sharename /u:mydomain\my +user
    Then at 17:40 you'll get a prompt for the password, then it will map the drive for you and your service will have access to that mapped drive.

    You can also add a check for this in your Perl code:

    unless { -d 'L:\' } { write_to_log_and_die(); }
Re: Win32 Daemon @INC
by UnstoppableDrew (Sexton) on Jan 07, 2008 at 19:57 UTC
    What user is the service running as, and does that user have the drive mapping in their profile ?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://660916]
Approved by Corion
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2021-05-13 10:28 GMT
Find Nodes?
    Voting Booth?
    Perl 7 will be out ...

    Results (134 votes). Check out past polls.