New feature requested - "Run as a service"

[GoogleCodeExporter]

New feature requested - "Run as a service".

Now, there is an option "Autorun". But this option is triggered when the
user login. I'd like setting "Run as a service" to run the program without
login of the user. Then you can connect from time to time to the computer
using RemoteAdmin and read sensors' values.

Thank you!

Original issue reported on code.google.com by Nikola...@gmail.com on 6 Apr 2010 at 5:31

[GoogleCodeExporter]

I have spent a lot of time already to implement code which would allow running 
the
Open Hardware Monitor as service and connecting with an Open Hardware Monitor 
GUI
process just to display the data from the service. Many of the problems are 
related
to remoting, user rights and having one EXE that can be run as service, pure GUI
application connecting to the service or as portable standalone application as 
it is
used now. Most of these problems could be solved.

But there is one big problem without solution: Session 0 isolation of Windows
Services on Windows Vista / 7. This causes all services to run on their own 
session,
which does not support any GUI system. This itself wouldn't be a problem, but 
somehow
the display driver is not accessible either. This means it is not possible to 
monitor
any data from the GPU when running as a Windows Service. 

This is the reason why I finally dropped the Windows Service code path, and
implemented the autorun option (which itself is a bit tricky with the Windows 
Vista /
7 UAC).

Original comment by moel.mich on 6 Apr 2010 at 6:54

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

May be you need to create TCP channel between service and GUI parts?

Original comment by Nikola...@gmail.com on 6 Apr 2010 at 7:12

[GoogleCodeExporter]

The communication between the service and the GUI part is not a big problem. I 
used
an IPC channel, but TCP would work as well. The problem is, that I can't access 
the
GPU hardware for monitoring in the Windows Service process. I can only access 
the GPU
sensors, fans etc. from a process in Session 1 (or greater), which requires a 
user to
be logged in. And having some monitoring code run in the Windows Service process
(Session 0) and some other (GPU monitoring code) in a user process in Session 1 
makes
things complicated. And you still can't monitor the GPU when nobody is logged 
in.

Original comment by moel.mich on 6 Apr 2010 at 9:16

[GoogleCodeExporter]

Issue 48 has been merged into this issue.

Original comment by moel.mich on 26 Apr 2010 at 5:55

[GoogleCodeExporter]

Hi !

Hmm, just my question:Do you have MS-MSDN access? I personally have and I could 
help
out with a question to a related forum there, if you find this helpful [if:Which
forum would be the best for this session 0 /GPU access problem?]?

++mabra

Original comment by mabr...@gmail.com on 26 Apr 2010 at 10:34

[GoogleCodeExporter]

A bit more information about the problem can be found on the NVAPI website from
NVIDIA http://developer.nvidia.com/object/nvapi.html

"NVAPI allows full access to NVIDIA GPUs and drivers in any UI and non-UI
application. Under Windows Vista, the application context using NVAPI must be
launched in Session 1 or higher."

The same problem as with NVAPI seems to occur when you want to use NVIDIA CUDA 
from a
service. A discussion and some kind of workaround can be found here
http://forums.nvidia.com/index.php?showtopic=93450

But the workaround requires a user to be logged in (as far as I know), because
otherwise no process could be launched into session 1. And NVIDIA says "There 
will be
a robust solution for Tesla customers regarding Session 0 isolation by the end 
of the
year.", so they consider this workaround not to be the greatest solution either.

I am not sure which MSDN forum one would use, because I do not know them in 
more detail.

Original comment by moel.mich on 27 Apr 2010 at 7:06

[GoogleCodeExporter]

I think that OHM as Session 1 service is not bad idea.
I guess that this application is not intended to be critical system protection
measure that automatically shuts down mission-critical IT service server in 
case of
emergency like overheat even if user is not logged ion the server.  Anyway, 
current
way (as start up application) does not provides any monitoring while user is not
logged in.
So not running/monitoring system while user is logged out does not matter at 
all.

Please separate UI part of the program (application) and data-gathering part of 
the
program as service. It will make this program much cleaner and useful.

Original comment by cant...@gmail.com on 24 May 2010 at 11:51

[GoogleCodeExporter]

As far as I understand, a Windows Service runs always in Session 0. I don't see 
any
way to start a Windows Service in Session 1, even if a user is logged in. 

The only thing I can do in Session 1 is start a normal application process. But 
to
control the starting and stopping of this process I will always need some kind 
of GUI
like a system tray icon or another application which will send control commands 
via
IPC (because we don't have the Windows Service starting and stopping control). 

So right now I don't really see where the advantage is to run two application
processes, one for the GUI and the other for the hardware access, except that 
you
could close the system tray icon (by closing the GUI process) temporarily 
without the
data collection from the hardware being stopped. The disadvantage of a two 
process
solution is all the IPC remoting stuff in the code and the confusion for a 
normal
user between the one process style (which should be supported anyway to keep the
application protable) and the two process style.

Original comment by moel.mich on 25 May 2010 at 7:04

[GoogleCodeExporter]

There are some ways to run service that can access GPU hardware and its display 
context.
1. In service property configuration > log on tab, specify local system account 
>
check "Allow service to interact with desktop" checkbox. Then service process 
can
access GPU hardware, even when running without user logged on. GPU Folding@HOME 
uses
this method to run GPU calculation while user is not logged on.
2. Use task scheduler. Specify new task that will run automatically when a user
logged on.

Advantage of separating GUI part and data gathering part:
OHM is quite heavy process in terms of memory consumption compared to other 
similar
monitoring utility because of its .NET based UI part. If OHM implement data 
gathering
part as service/WMI provider, then relatively simple and small application can 
update
tray icon only. Full GUI client (and with heavy memory footprint) will run only 
when
it is activated from tray icon. This separation of  data gathering part and 
full-GUI
application will reduce its effective memory footprint significantly.

Additionally, completely different program like Sidebar gadget can access the 
data
without .NET UI-related memory burden while the full- UI client application is 
not
running.

Original comment by cant...@gmail.com on 25 May 2010 at 1:32

[GoogleCodeExporter]

I think I checked suggestion (1) already, with the result that it does not work 
in
Windows 7. Setting "Allow service to interact with desktop" may work in XP, but 
in
Vista / 7 you get access to some emulated Windows Service Desktop and you don't 
have
access do the real hardware GPU. That's what they write here
http://folding.stanford.edu/English/FAQ-NVIDIA#ntoc14 as well. 

I am using (2) already (at least for Vista / 7), but technically it runs just 
as a
normal application process and not as a Windows Service (and can't be 
controlled from
the Windows Services Dialog).

About memory: It is pretty tricky to judge the memory usage of an application
correctly, above all when you compare native applications and .NET 
applications. A
bit more details can be found here:
http://stackoverflow.com/questions/1343374/reducing-memory-usage-of-net-applicat
ions

Last time I checked I got the impression that things are not as bad as they 
might
seem just from looking at the Task Manager.

In the Open Hardware Monitor, both the GUI and most of the sensor reading code 
are
written in C# and run in .NET. So one would have to rewrite the sensor reading 
code
to C++ to get rid of the .NET framework for a hardware monitoring only process.

If we keep both GUI and hardware code in C#, then I can just as well unload the
complete GUI related memory when the application is minimized. Altough I doubt 
that
the GUI uses a very large amount of memory that would justify the effort.

But before starting to rewrite the hardware related code to C++ and splitting 
the
application into two seperate processes, the memory usage should be analyzed a 
bit
more in detail to see if there really is a problem which requires removal of 
the .NET
framework when monitoring in the background.

Original comment by moel.mich on 25 May 2010 at 2:50

[GoogleCodeExporter]

Hi !

It looks like, that - in opposite to the most people here - I am only/mainly
interested to have a tool, which shutdown a box in thermal ciritcal situations.

A good compromise could be to build a WMI provider ["If OHM implement data 
gathering
part as service/WMI provider, then relatively simple and small application can 
update
tray icon only."]. There is an article in codeproject, which gives more insights
[http://www.codeproject.com/KB/system/WMIProviderExtensions.aspx]. Bu I do not 
know,
if this solves the mentioned problem to access cpu and gpu.

Just my note.

br

++mabra

Original comment by mabr...@gmail.com on 25 May 2010 at 5:21

[GoogleCodeExporter]

A auto-shutdown option should be implementable in both the current application
process version of the Open Hardware Monitor or a Windows Service based 
version. 

Implementing a WMI provider does not solve the GPU access problem in Windows 
Services.

I did a short test about the memory load, here the results (on a Windows 7 x64 
system
with 4GB RAM and not much memory pressure).

ConsoleApplication (just an almost empty .NET application)
Commit Size: 17.2M
Working Set: 9.3M
Private Working Set: 2.3M

OpenHardwareMonitor
Commit Size: 39.6M
Working Set: 42.7M
Private Working Set: 16.1M

HWMonitor
Commit Size: 2.8M
Working Set: 10.1M
Private Working Set: 2.5M

As far as I understand, commit size is the total currently reserved amount of 
private
memory for the application, and depends a lot on the peak memory usage of the
application (and the overall memory pressure on the system). This is larger 
even in
an empty .NET application when comparing with HWMonitor. But I think this mainly
comes from the fact, that the .NET memory manager does not agressivly free any
reserved memory (used under peak load) as long as the system is not under an 
overall
memory pressure. I think this value is not too important.

The working set contains both the sharable and the private working set. 
Depending on
how many standard libs an application uses there can be differences.

The private working set is the memory an application actually uses and can't 
share
with other applications / system. This value is small even for a .NET 
application.
This is also a point where the OpenHardwareMonitor does not perform too great. 
I will
see if there is anything obvious where memory gets wasted.

Original comment by moel.mich on 25 May 2010 at 5:59

[GoogleCodeExporter]

Original comment by moel.mich on 23 Jun 2010 at 7:15

• Changed state: NeedsInfo

[GoogleCodeExporter]

Services should not be running as UserPrograms. For programs, have to be 
running "as service", use ScheduledTask.

http://social.technet.microsoft.com/Forums/en-US/winserverMigration/thread/98a97
aee-c62b-4683-94ab-3777899cf7de/
For runnig a bat file at computer start You can use "windows scheduler".
Start->Control Pannel->Scheduled Tasks->Add scheduled task
In wizard you can check the option "When my computer starts".
So the task will start as the computer starts without need to sign on - like 
any "windows service".

http://www.howtogeek.com/howto/windows-vista/create-administrator-mode-shortcuts
-without-uac-prompts-in-windows-vista/

Original comment by vaclav.b...@gmail.com on 14 Jul 2011 at 1:42

[GoogleCodeExporter]

I have been able to get OHM to run "as a service" (headless) via "schtasks". 
http://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx

However, I am seeing it crash randomly after a number of days, we're using the 
WMI interface to pull data. Trying to debug this.

I am also not seeing the GPU temperature, as described above. (It's an NVidia 
laptop GPU.)

Original comment by claud9...@gmail.com on 10 Jan 2014 at 11:42