0

In my application, I have a C process created which will be re-spawned if the process dies. Now I have a requirement to know if the process is spawned for the first time(after system reboot), due to which function X will be called, or if the process got re-spawned after a crash(runtime) due to which function Y will be called.

I tried creating temp files by the use of command mktemp() but the files seemed to be persistent even after the reboot.

So what would be best way to do it?

Manoj
  • 23
  • 6
  • Is there any information or data store in the file? – Andrew Henle Feb 01 '17 at 13:55
  • @AndrewHenle No there is no information in the file, it'll just be used as a way to find out if its the the process spawned for the first time after boot or re-spawned after a crash – Manoj Feb 01 '17 at 16:00
  • (create and) attach a shared memory segment. These are persistent after process temination (or crash), but don't survive reboot. – wildplasser Feb 01 '17 at 16:25

3 Answers3

2

mktemp creates files in /tmp (by default). In many distributions, /tmp is persistent (i.e. disk-backed, not memory-backed).

What you are looking for is to create a file in a memory-backed mount. Typically these are the tmpfs mounts. For example, on my Arch Linux laptop, my tmpfs mounts are:

$ mount | grep tmpfs
[..]
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)

So on this system, I can open and write to files in /dev/shm/ on /run and they will be backed by my memory, they won't persist across boots and the access will be fast and cheap.

Back to your question, it seems that you can change the directory used by mktemp. Quoting the man page:

-p DIR, --tmpdir[=DIR]
              interpret  TEMPLATE relative to DIR; if DIR is not specified, use $TMPDIR if set, else /tmp.  With this option, TEMPLATE must not be
              an absolute name; unlike with -t, TEMPLATE may contain slashes, but mktemp creates only the final component

EDIT - few more things:

  • this is all distribution-dependent; other distributions may mount tmpfs at /tmp.
  • interestingly, /dev/shm is where shared memory objects created with shm_open are stored.
Ezequiel Garcia
  • 1,037
  • 8
  • 20
  • Actually the application under development is a embedded application having powerpc architecture.. some script had to be run to delete the files in /tmp directory everytime the system reboots, which was not run, thereby causing the files in the /tmp directory to be persistent. Anyways thanks for the suggestion @Ezequiel Garcia. It worked out :) – Manoj Feb 02 '17 at 15:41
  • Well, I guess that depends on what you want `/tmp` to be. You want a disk-backed temporary storage, and you want to remove it upon reboots? Then fine. On my embedded platforms, I mount tmpfs on `/tmp` so I don't use disk for it (and don't need to remove anything on reboot). – Ezequiel Garcia Feb 02 '17 at 16:26
2

I don't see the problem with persistent /tmp. You can check timestamps and compare them with boot time.

boot time in epoch:

stat -c %Y /proc/1

file creation time in epoch:

stat -c %Y filename.tmp

The biggest advantage of this approach is portability, since it is not dependent on distro-specific tmpfs settings

Bruno9779
  • 1,551
  • 2
  • 14
  • 31
  • But the crash of the process is unpredictable so cant rely on the timestamp concept to determine if the process is spawned the first time or spawned after a crash. – Manoj Feb 01 '17 at 16:02
  • Why not? If the difference between boot time and creation time is longer than ej 2*booting time, you know it is a respawn – Bruno9779 Feb 01 '17 at 17:29
0

Create the file using e.g. open, then immediately remove the file (with unlink). Since you have it open the file will still be available to you, but as soon as it it closed (explicitly with close or because the OS closes it when the process exits (crash or not)) then it will be like it never existed.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • 1
    I think the idea is that another process will check for the existence of the file to decide if the process is already spawned. By deleting the file you prevent this scheme to work... – fjardon Feb 01 '17 at 13:59
  • The idea is, the file existence will only help me to determine whether boot-time function( function X w.r.t to the question asked) need to be called or the run-time function need to be called. So I'm not going to write anything to the file, I would merely use its existence to decide which function need to be called. – Manoj Feb 01 '17 at 16:53