Notification in Event Structure When Linux is Shuting down

[Paolo_P]

Hi,

The Event Structure is able to catch the information when Windows is shutting down is the event "Application Instance Close?".

That event don't work in Linux OS. It exist a workaround in Linux with CIN code, but since CIN has been deprecated with LV 2011, the is no actual workaround.

http://digital.ni.com/public.nsf/allkb/C2470DFFFC71D47F86256F70005891C6?OpenDocument

[dadreamer]

As I know CINs continue to work even on the recent LabVIEW 2017, although they're considered to be deprecated. If that workaround solves the problem, then just use it as is. If you are afraid, that CINs will stop working some day, then you might recompile the CINs into DLLs from the sources, which are included in signalsSource.tgz. The same applies to 64-bit LabVIEW - either CIN or DLL should be compiled as 64-bit and the LV code should be tweaked.

[wiebe@CARYA]

But why do Linux users have to use a CIN or DLL? It's technically possible, so why isn't this working in Linux? Seems like a bug to me.

[dadreamer]

---

wiebe@CARYA wrote:

---

But why do Linux users have to use a CIN or DLL? It's technically possible, so why isn't this working in Linux? Seems like a bug to me.

I cannot give a clear answer to this but maybe some one from R&D could? Just had a quick test on Ubuntu 15.04 and LabVIEW 2016 64-bit and both Application Instance Close and Application Instance Close? do not work on OS reboot/shutdown. But surprisingly it works when selecting File -> Quit from the context menu. Based on this I can assume that:

- SIGTERM doesn't reach LV somehow

- LV lacks SIGTERM processing or interpreting

I don't believe that shutdown is so fast that LV doesn't have enough time to process the signals. But I'm not an expert in Linux, I still learn things.

[rtollert]

AFAIK, SIGTERM is not what you want, for the simple reason that it is only ever really used by the init system, and it probably doesn't give a hoot about IPC or process dependencies. In other words, if you actually caught SIGTERM from LabVIEW, I am not entirely sure if you can rely on the GUI (X11 server) still running, or anything else for that matter. It should be viewed as the absolute last resort in shutdown events.

Orderly UI shutdowns on Linux never use signals. Instead, they use XSMP, and handle e.g. the SaveYourself or Die messages. LabVIEW doesn't support those, either, so I think you're still going to need a shared library, but if you do go down that route, I think you'll have better luck dealing with XSMP than with signals.

[dadreamer]

---

@dadreamer wrote:
The same applies to 64-bit LabVIEW - either CIN or DLL should be compiled as 64-bit and the LV code should be tweaked.

---

Well, I have attempted to port those 32-bit CINs to 64-bit analogs but failed. Suddenly it turned out that CIN link chain in 64-bit LabVIEW on Linux is broken. If I try to load *.lsb file into CIN, LabVIEW reports 23 error "Bad external code format.". Some deeper code digging shows that PrepELFSharedLibResource procedure is stripped down and lacks some basic parts, e.g. *.so extraction from the resource to the temp folder, library load, LVSBHead analysis etc. That's a little strange given the fact that 64-bit CINs work just fine in 64-bit LabVIEW on Windows. Not sure about Mac though (gonna check that later, maybe). I see no reason to fill in a bug report 'cause CINs are obsolete and it's very unlikely to be fixed. So, if anyone needs this shutdown events available in 64-bit LabVIEW (s)he definitely should write a shared lib for it.

[dadreamer]

Oh, I just noticed that NI has reworked the old article to match the new format. It is now Handling Linux System Signals in LabVIEW. They also removed all the related examples and the CINs sources. I think it won't be superfluous to save the old article somewhere (say, here) for those who still want to use old CIN approach.

---

Acquiring System Signals Like SIGTERM in LabVIEW

Primary Software:
Primary Software Version: 7.1
Primary Software Fixed Version: N/A
Secondary Software: N/A

Problem: The usual behavior of LabVIEW on Linux is that a LabVIEW application quits when a signal like SIGTERM is received. How can I handle these signals in LabVIEW? For example, how do I catch the SIGTERM signal to cleanup operations before LabVIEW exits or to disregard the signal if I do not want it to close?

Solution: The attached signals.llb can be copied to the user.lib folder of labview. It contains two VIs:

- The VI signalHandler.vi can be used to set up a signal handler for a specified signal. This handler will set an occurrence, which can be used in the code to perform user defined actions after the signal was received.

- The VI kill.vi can be used to send any signals from LabVIEW to the application itself (when the PID input is not connected) or to any other application on the system.

The CIN source code can be found in the attachment signalsSource.tgz

The attached VIs waitForSignals.vi and testWithTwoSignals.vi are examples how to use the signalHandler.vi

Related Links: NI LabVIEW Full Development System for Linux

Attachments:

- signals.llb

- waitForSignals.vi

- testWithTwoSignals.vi

- signalsSource.tgz

Report Date: 12/20/2004
Last Updated: 02/09/2014
Document ID: 3GJ94MHU

[dadreamer]

---

@dadreamer wrote:

Not sure about Mac though (gonna check that later, maybe). 

---

Well, I've checked out some things on Mac OS X Sierra with LabVIEW 2016 64-bit. I see that both Application Instance Close and Application Instance Close? work fine on OS reboot/shutdown. So Mac doesn't suffer from this signals issue (maybe something's implemented in another way or there are specific internal differences between Linux and Mac OS). Besides of that I see that 64-bit CIN link chain is also unworkable as on Linux. PrepExternalCode procedure of LVManagerMinimalInterface class is just a stub and does nothing except returning 53 error ("Manager call not supported."). I don't know if it was always so from the very beginning of 64-bit LabVIEW or it might be functioning in former times (LV13 or 14?). But now it's clear that 64-bit CINs are completely buried on Linux and Mac OS. Miraculously they are still working on Windows though.

[rolfk]

As far as I know CINs got depreciated somewhere between LabVIEW 7.1 and 8.5 and accordingly the cintools never have been ported to support any of the platforms that were released after that. That includes all the RT platforms except Pharlap, and every single 64 bit platform. And the necessary cintools to create CIN resources were defnitely removed in LabVIEW 2011. The 32 bit versions of LabVIEW still are able to load CIN resources created in earlier versions and probably will continue to do so, but the 64 bit versions can for obvious reasons not load a 32 bit code resouce. In fact LabVIEW 32 bit for Windows even supports loading CIN resources created with the Watcom C compiler for LabVIEW for Windows 3.1, since that were 32 bit code resources too, just with a somewhat different object file format, then called REX. The 64 bit versions of LabVIEW most likely do not even contain full support to load CINs even if someone would magically be able to create them in the correct format. But without lvsbutil.exe and the according object files lvsb.lib, cin.obj and lvsmain.exp in the necessary 64 object file format, creating such CINs is simply impossible too.

As to support of the shutdown event under Mac, that is not so strange. LabVIEW started out on the Mac and Mac OS Classic supported a proper shutdown event in the application event loop that every Mac application had to implement in order to be a fully well behaving Mac GUI application. That event was properly handled from the start and when everything was ported to Windows, this event loop from the Mac was in fact ported to the Windows version and then hooked into the Windows message loop. This is the so called root loop that has come up every now and then. Much of the event handling in LabVIEW was and most likely still is even under Windows still very much modeled around the Mac event loop.

The Unix platform was a very different animal in that respect, here the GUI handling is completely seperate from the process handling, with GUI being handled by the X Windows system and process handling by the Linux kernel. And X Windows does not really care about processes at all, so the event handling under LabVIEW for Linux which is logically mainly coupled with the GUI events from X Windows doesn't have an easy way to hook into the kernel events. Add to that the fact that there are different approaches under Unix/Linux for just about everything that happens since there were so many architects building on that building, many of them having completely opposing ideas about how to approach things and you can understand why it was probably not so easy and hence not a high priority item to add something like process shutdown events into the event structure under these platforms. Even nowadays with Linux being in fact the only supported Unix version in LabVIEW, it still is a challenge since Debian (and Ubuntu and all its derivatives) is in many aspects a different Linux than Red Hat, and that is different to Suse or Sun, ääh Oracle Solaris Linux, and that is again different than the kernel system used for the Linux RT platforms.

[rolfk]

---

@dadreamer wrote:

That's a little strange given the fact that 64-bit CINs work just fine in 64-bit LabVIEW on Windows.

---

I'm not sure how you got that impression. Unless you have some super secret access to unreleased NI tools that you got somehow, it was never possible to create 64-bit CINs even under Windows. LabVIEW 2009 was the first version that was released with a 64-bit version for Windows and there are no CIN libraries and utilities in the cintools directory at all (and since LabVIEW 2011 also not in the 32-bit version anymore). And LabVIEW 64-bit can not load 32-bit CINs for the same reason as it can not load 32-bit DLLs (CINs are on all Windows NT platforms just a DLL, with very specific function exports and packaged with the lvsbutil tool into some resource format for inclusion as code resource into VIs).

That said, I see nothing in the posted sigterm code that would pose any problems to port to a shared library solution. It's basically just taking the gist of the code and putting it into some functions and throwing away the CIN specific function declaration. Nothing at all like rocket science, although compiling C code for Linux can at times seem to be like rocket science 

The approaches discussed so far both do strike me as not equivalent to what the aforementioned event structure event is meant to do, though it may be sufficiently similar to appear to work like that. XSMP sounds odd in a way since it is just the termination of the X Windows session itself, which in true Unix tradition is in fact completely independent of process termination. It may be enough in the case of LabVIEW, since LabVIEW will fail to startup without an X Manager to create a session on except on the headless RT targets or when you do some ini file finickery which still may or may not work.

And the signals route has the problem that it only gets the sigterm signal when someone else has sent this to the LabVIEW process but will fail to notice you when LabVIEW is shutdown itself. Maybe there is another possible signal to catch but I would think that that has at least a potential race condition in that by the time your code gets to see it, the LabVIEW process may already have terminated.

[dadreamer]

---

@rolfk wrote:
The 64 bit versions of LabVIEW most likely do not even contain full support to load CINs even if someone would magically be able to create them in the correct format. But without lvsbutil.exe and the according object files lvsb.lib, cin.obj and lvsmain.exp in the necessary 64 object file format, creating such CINs is simply impossible too.

Very well written as always, but there was one thing I already did and showed here - you definitely can create 64-bit CINs on Windows and they do work in 64-bit LabVIEW on Windows just fine. There's even no need for lvsb.lib, cin.obj and lvsbmain.exp. All you need is an IDE which's able to generate native Windows libraries. Well, I tried in Delphi XE by recreating the CIN header and the basic CIN entry points (CINRun etc.). Of course, some fields in the header required switching from 4 bytes to 8. As for lvsbutil I had to alter PLAT FourCC fork from "i386" to "wx64" (it may be done in any HEX editor). Or there's mighty R resource API, that might be used instead of lvsbutil (RSaveResFile and friends). I understand that to use any of LV Manager APIs it's needed to define the corresponding functions dynamically, but it's not that hard to do. After all the tests I could conclude that 64-bit CINs are fully functional and their linker code is properly rewritten from 32- to 64-bit LabVIEW. Okay, I found this Idea on the forums and started to ask myself if the very first 64-bit LV versions for Mac and Linux could contain the original linker code in a workable state or not. Now I'm most inclined to "No" answer because of the results I've found (look at the messages above). I would be glad to be wrong, when you (or anyone having 13-14 64-bit versions for Mac and Linux) shed some light on the truth.