LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

smtp will not work while user is logged off

Hi,
    I've been doing some testing with the smtp functions of labview.  Everything seems to be working great as an executable, sending emails to my mail server.  I knew it wouldn't work as soon as I logged off my computer though, since exe's can't run without a user.  But I've read on many sites (misc, microsoft, even this forum) about setting this exe to run as a service.  This helps a little, the service runs and does what it's supposed to do EXCEPT sending the email.  As long as a user is logged on, the service works and sends emails, but as soon as I log off, the smtp portion starts to fail.
   Here is the error ID and message I get out of it:
 
62.000000

TCP Open Connection in NI_SMTPEmail.lvlib
:SMTP Email Open Session.vi:3->NI_SMTPEmail.lvlib
:SMTP Email Send Message Charset.vi:2->NI_SMTPEmail.lvlib
:SMTP Email Send Message.vi:1->ViceVersaLogReader.vi
 
ViceVersaLogReader.vi is the vi that I created to send the emails.
I've made sure to have the service run as either local system or my admin account, neither helps.
 
Anything else I can try?
 
thanks,
-Jes
0 Kudos
Message 1 of 9
(3,773 Views)
Also,
     I've tried using the "small" version of the smtp .vi and I get the same results.
Is there some type of debugging or other logging to do to find out what might be causing the problem? Is it a labview issue of the smtp not getting the same rights as the main vi running as a service?  Is it windows that just won't allow smtp to work at all when no user is logged on?  Or does LabView just not let smtp run as a service?  How could I figure this out?
 
thanks,
-Jes
0 Kudos
Message 2 of 9
(3,754 Views)

Hi Jes,

      Recently, while trying to get a test-app to work for any domain login, I used "Scheduled Tasks" to run an EXE on startup - it ran with local "admin" rights.  Seems like there might be some possibility here - using Scheduled Ttasks - assuming it's not what your doing already!  Smiley Wink

Cheers.

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 3 of 9
(3,738 Views)


@jesse Larsen wrote:
Hi,
    I've been doing some testing with the smtp functions of labview.  Everything seems to be working great as an executable, sending emails to my mail server.  I knew it wouldn't work as soon as I logged off my computer though, since exe's can't run without a user.  But I've read on many sites (misc, microsoft, even this forum) about setting this exe to run as a service.  This helps a little, the service runs and does what it's supposed to do EXCEPT sending the email.  As long as a user is logged on, the service works and sends emails, but as soon as I log off, the smtp portion starts to fail.
   Here is the error ID and message I get out of it:
 
62.000000

TCP Open Connection in NI_SMTPEmail.lvlib
:SMTP Email Open Session.vi:3->NI_SMTPEmail.lvlib
:SMTP Email Send Message Charset.vi:2->NI_SMTPEmail.lvlib
:SMTP Email Send Message.vi:1->ViceVersaLogReader.vi
 
ViceVersaLogReader.vi is the vi that I created to send the emails.
I've made sure to have the service run as either local system or my admin account, neither helps.
 
Anything else I can try?
 
thanks,
-Jes


Error 62 sounds really like a permission problem. TCP Open Connection is a LabVIEW primitive and ultimately goes to the Winsock library which refuses to allow creating a connection so there is not really to much you could do in terms of debugging inside LabVIEW. Probably the Windows firewall is disallowing to connect to low ports (<=1024) when no user is logged in. There certainly needs to be some way somehow to circumvent that for a service but I wouldn't know of the top of my head.

Try to investigate into that direction on the Microsoft and MSDN site.

Rolf Kalbermatter

 

Rolf Kalbermatter
My Blog
Message 4 of 9
(3,730 Views)
tbd,
    Sorry, that is exactly what I've been doing.  I'd use task scheduler to make the program run at a specific time when I'm logged off.  I'd set the user as the admin.  Even if i logged off and logged in as a different user, it would still work. Just not if a user was not logged in.  I'd also have the task scheduler run a batch file that would turn the service on and off. And this would not help at all.  I'd also have the service set to be automatic so it would start at restart.  Inside the program i have it looping to keep trying to send an email every minute.  After restart, it would never work (but it would do all the other tasks, just no email) but as soon as i logged in, then the email would work.
 
thanks,
-jes
0 Kudos
Message 5 of 9
(3,716 Views)
rolfk,
    Thank you for your advice.  I'll start playing with the firewall settings and logs.  I'll also try this on another computer.  Thanks!
 
-jes
0 Kudos
Message 6 of 9
(3,714 Views)

Hi Jesse,

      Did you ever find a solution or work-around for this?  What OS are you using? (I'm unable to reproduce this under Win2K.)  I'm using raw-socket pings for another app, and XP required a registry-hack to allow Domain Users to send pings (Admins weren't restricted.)  If this problem was socket-permissions related, maybe so is the registry-hack.  Google "AllowUserRawAccess" if interested.

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 7 of 9
(3,576 Views)


tbd wrote:

Hi Jesse,

      Did you ever find a solution or work-around for this?  What OS are you using? (I'm unable to reproduce this under Win2K.)  I'm using raw-socket pings for another app, and XP required a registry-hack to allow Domain Users to send pings (Admins weren't restricted.)  If this problem was socket-permissions related, maybe so is the registry-hack.  Google "AllowUserRawAccess" if interested.


While it's probably related I don't think that RawSocket access would help here. SMTP is TCP/IP based and that is a distinct protocol in the Winsock library and not considered a raw socket. I can understand why raw socket access would be restricted of course, as that is the lowest level socket layer and you can construct any datagrams on there, including malicious ones to try to create DOS attacks or exploit socket library weaknesses on particular targets. Under Unix, raw socket access was restricted for a long time already.
 
It's most probably that at least from XP SP2 onwards winsock access is completely restricted for non authorised users. Trying to run the service in the local system account could help. But that would mean installing the program as a real service I'm afraid and that requires specific support in the application too, to communicate with the service manager. Something like http://www.citengineering.com/pagesEN/products/service.aspx might be required for that.
 
Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 9
(3,564 Views)
Sorry guys for taking so long to get back to your responses.  I can't rememeber exactly what I learned about this issue, but I gave up trying it in labview.  I used Visual Basic and it worked perfectly almost right away. Created an exe, made that into a service, and it runs fine with no user logged in.  Sends the emails perfectly.
 
So I don't know what the issue was, but with labview's exe, it wouldn't send the email, but with VB's exe, it would send it.  Weird.
thanks for your help.
-Jes
0 Kudos
Message 9 of 9
(3,499 Views)