Consider different/configurable name and location for .lgd-nfyx pipes

[matthijskooijman]

Currently, lg seems to create pipes named .gld-nfy<handle> in the current directory (where I believe handle is just an index of opened handles inside the current process). This approach has two problems:

1. It assumes that the current directory is writable, which might not always be the case (I'm running into this issue with a read-only rootfs, where only places like /run, /var/tmp and /tmp are writable).
2. If multiple processes using lgpio are started in the same directory, they will overwrite each others pipes (this is hypothetical based on looking at the code, I have not actually tried this).

Maybe it would be good to revisit the naming to fix either or both of these?

For 1., I would suggest using /run/user/<uid> to create these pipes. This seems to be the standard location on modern Linux distros, as defined by the FHS (See for example https://renenyffenegger.ch/notes/Linux/fhs/run/user/uid/index). Rather than hardcoding just this location, I guess it would be good to make it configurable, and also provide fallbacks. I can imagine to use the first of the following that is writable: $LG_RUNTIME_DIR, $XDG_RUNTIME_DIR, /run/user/<pid>, '/tmp/, .(I'm not sure about/tmp`, using that might be a security risk).

For 2., I would suggest maybe using something like .gld-nfy-<pid>-<handle>, which should make the filenames unique.

However, while writing this, I wonder if it would not be possible to simply use a anonymous socketpair (see https://man7.org/linux/man-pages/man2/socketpair.2.html) rather than an on-disk fifo. IIRC this supports pretty much the same thing (bidirectional data transfer using read()/write(), but does not need to be stored on disk (you would just need a way to return the FD to the calling program, rather than just the handle). I do not have a full picture of the architecture involved, so it's likely that I'm missing some part that prevents this, but maybe you just haven't considered this option?

[joan2937]

All good points. I wasn't happy having the pipes in the local directory. Unfortunately I do not remember my thinking at the time. I think point 2) is handled by Linux as I certainly had multiple non-conflicting processes during testing.

I like your suggestions. I will look into this again but can not give a time-scale. If you have a working solution I will happily accept a pull request.

[matthijskooijman]

All good points. I wasn't happy having the pipes in the local directory. Unfortunately I do not remember my thinking at the time. I think point 2) is handled by Linux as I certainly had multiple non-conflicting processes during testing.

Thanks. I recently needed something like this for another project and found that the default anonymous pipes were cumbersome, since they are unidirectional (so you'd need two, and thus juggle 4 fd's...). Then I found that a socketpair (of the unix stream type) can do pretty much the same, but bidrectional.

I like your suggestions. I will look into this again but can not give a time-scale. If you have a working solution I will happily accept a pull request.

Cool! I would love to make a pull request, but the meadow for this project already has a big herd of yaks, so I cannot really spare the time...

[joan2937]

I suggest unless I can think of a better solution you will need to set the working directory when your programs start.

The daemon rgpiod has the -w option.

The other programs will pick up their working directory from the LG_WD environment variable. E.g.

export LG_WD=/tmp

[txoof]

@joan2937 I'm working to wrap my head around this. I understand that a working directory needs to be set (-w option) where users can have the ability to create service handles.

What I'm not sure about is where that needs to be set on a raspbian system. Can you offer any links to documentation or clues as to how this can be sorted out?

EDIT and RESOLTUTION:

For my purposes, this impacted a daemon service that was failing to start due to not having write permissions. If anyone else stumbles on this, the solution is to add the following lines to the [Service] section of the unit file:

[Service]
... 
RuntimeDirectory=<your name of choice>
WorkingDirectory=/run/<your name of choice>
``

[craigerl]

I need to run my app on a read-only filesystem which uses files in the working directory, so the working-directory trick isn't working for me. Is there a way to tell lgpio to use /tmp for these pipes? or /run? Is there a list of pipe names lgpio needs? so far, i've been making a fifo (mkfifo) for,

mkfifo .lgd-nfy0 .lgd-nfy1 .lgd-nfy2 .lgd-nfy-3 .lgd-nfy3 .lgd-nfy4 .lgd-nfy5

.lgd-nfy-dash-3 was a new one, couldn't create it, crash....

[txoof]

I don't have much experience with ro systems, but would it work to just specify /tmp/spam_ham/ as your working directory?

[craigerl]

I don't have much experience with ro systems, but would it work to just specify /tmp/spam_ham/ as your working directory?

My application uses files in its working directory ($HOME). configuration files, graphics, etc.

I went through the lgpio source and honestly couldn't find where it names the pipes... the number appears to be a "handle".

So far, as it litters the working directory with pipes i see .lgd-nfy#, and sometimes .lgd-nfy-# (dash before the number). I can mkfifo all of these if I know what they all are in advance, and that will work until I get everything off of lgpio, and on to gpiod.

thanks,
-craig