What is timetosaygoodbye.fifo?

[hoshsadiq]

The file keeps getting created and I am wondering what it is and if it is actually a necessary file? If so, it would be nice if it can be named something more appropriate as it I've been removing it over and over again without knowing what creates the file (accidentally stumbled upon it earlier because for some reason x11docker didn't have permissions to write to it).

[eine]

timetosaygoodbye is used ~60 times in the script: https://github.com/mviereck/x11docker/blob/master/x11docker. Hence, I'd say that it is a necessary and relevant resource (not a file, but a pipe/channel):

`Timetosaygoodbyefifo="timetosaygoodbye.fifo"    # Message channel for --init=openrc|runit|sysvinit to shut down on x11docker signal`

I have also found it to be left after running x11docker, however I did not need to remove it. I.e., I just removed it when I wanted to have a clean workdir.

Rather than worrying about the name of it, I'd be interested on knowing why is it that this file is not always removed.

[mviereck]

@eine quoted the essential explanation: It is a pipe to tell containers that it is time to say goodbye (i.e. to shut down). x11docker could do without it, but it makes things easier with some init setups.

I'd be interested on knowing why is it that this file is not always removed.

How / where does the file remain? It is created in the cache folder and should be removed along with the rest of the cache when x11docker terminates.

[eine]

Unfortunately, I have not been able to reproduce it consistently. That's why I didn't open an specific issue yet. Every once in a while I see that the file exists in directories where I called x11docker from (not in the cache folder). As said, I just ignore/remove it. I'll try to gather some more info next time I find it.

[hoshsadiq]

Ah, I must be blind, didn't see the comment. Anyway, yeah now that you mention it, I've not seen it leave the file consistently either. Could it possibly be that it happens when x11docker doesn't exit cleanly?

[eine]

Could it possibly be that it happens when x11docker doesn't exit cleanly?

Yes, I'm quite sure about it. However, there seem to be multiple non-clean ways to exit. Sometimes the X server or the container were/are not properly removed. In such contexts, it is easy to understand that x11docker didn't exit cleanly. However, it is strange that in other contexts both the X server and the container are properly removed but this file is left behind.

[mviereck]

I have no real idea yet. Just one attempt: Function main() runs some functions:

  declare_variables    # Timetosaygoodbyefifo="timetosaygoodbye.fifo"
...
  create_cachefiles    # Timetosaygoodbyefifo="$Sharefolder/$Timetosaygoodbyefifo"
...
  setup_fifo           # mkfifo $Timetosaygoodbyefifo

There is a time where the file has no path: Timetosaygoodbyefifo="timetosaygoodbye.fifo"

If the file somehow is generated without the path specifiation, it would appear in the current working directory instead in cache. Though, I currently have no idea how this could happen even on failed startups.

Edit: If x11docker terminates, it tries to write in saygoodbye(), but only if the file exists:

  [ -e "$Timetosaygoodbyefifo" ] && echo timetosaygoodbye >> $Timetosaygoodbyefifo

Could the -e check somehow fail?

[mviereck]

I just slightly remember that I once had timetosaygoodbye.fifo at a wrong location, too, and did a fix for this. IIRC the -e check in function saygoodbye() was missing. The wrong creation could happen if pressing CTRL-C immediatly after startup.

@hoshsadiq Which x11docker version are you using? If it is an old one, please update to the current release and give me a new feedback if the issue still occurs.

[hoshsadiq]

I'm using 6.5.0, upgraded before I raised this issue. It may be that I've been confused with a previous left over file. I don't exactly remember.

Anyway, I just did a find on my home dir for this file, seems the latest one was on 28 Sept. Outside that there's a few in the .cache dir which are more recent, but I'm guessing the ones in .cache are working as expected.

I've removed all of these files, so if I see this file again, I will update the ticket.

[mviereck]

seems the latest one was on 28 Sept.

There is a good change that the bug is fixed already; in october I've released 6.3.0 with a big bunch of code changes. At about that time I've also made a lot of tests with CTRL-C interruptions.

For now I'll assume that the bug has been fixed meanwhile.

I've removed all of these files, so if I see this file again, I will update the ticket.

Thank you for reporting it, and yes, please report again if it occurs again!