Hello @jack-liuhang
Sorry for my late verification.
Yes your observation is right.
My reproducing steps:

1. Run daemon with default port 3190
2. Run user: success
3. Check fifo activity using strace: read write okay
4. Run another daemon on port 3195 and still keep old daemon running
5. strace seeing the read from old daemon on fifo but the user now NOT writing to that old fifo anymore
6. Now rerun client on new port 3195, fifo now working for reading and writing

Conclusion: fifo already been renewed and used by new daemon

Next actions:

1. Stop the old daemon
2. Stop the user
3. Rerun the user, now fifo is removed and it is exactly the issue you described:

$ dlt-example-user hello -n 1000
[20089.689247]~DLT~582893~INFO     ~FIFO /tmp/dlt cannot be opened. Retrying later...

None of new daemon or new user process can communicate since no fifo there.
=> This is a real bug and new mechanism/fix needed here
Thanks a lots for the report!
FYI @michael-methner

Proof:
When dlt-daemon on default port 3190 (pid 9593) is running and we start daemon on 3195 (pid 10392), the old fifo is deleted (fd 3 of 9593) and the new one is created and link to fd 3 of pid 10392.
Issue comes when we try to kill 9593, the fifo also be removed, no more fifo for 10392.

Dr.Mint@:/proc/10392/fd  
$ ll /proc/9593/fd/3
lrwx------ 1 lum3hc lum3hc 64 Jun 21 15:27 /proc/9593/fd/3 -> '/tmp/dlt (deleted)'
Dr.Mint@:/proc/10392/fd  
$ ll 3
lrwx------ 1 lum3hc lum3hc 64 Jun 21 15:34 3 -> /tmp/dlt|
Dr.Mint@:/proc/10392/fd  
$ ll /proc/9593/fd/3
ls: cannot access '/proc/9593/fd/3': No such file or directory
Dr.Mint@:/proc/10392/fd  
$ ll 3
lrwx------ 1 lum3hc lum3hc 64 Jun 21 15:34 3 -> '/tmp/dlt (deleted)'

Hello @duvanan13
Kindly work on this issue
Your task:

1. Reproduce the scenario
2. Propose a fix/new implement for new mechanism
3. Crosscheck for Autosar std (any violations? harm? vulnerability? unittest?)
4. PR and review

Regards

RCA: In dlt init phase 1, setup for local fifo also trying to remove the exist one (unlink), however the fd not yet close (fd 3). Then later on, the old daemon at exit phase will try to remove the fifo if detecting fifo linking to fd.
Currently no solution proposed yet, kindly continue to research.
Proposing method: Check modified date fifo

Thank you for revisiting the question and investing your time in it.

Solving this issue thoroughly is indeed challenging.

Consider not unlinking tmpFifo directly. For instance, quickly check for IP binding conflicts before unlinking FIFO operations. Additionally, preventing new daemons from being created on a multi-user machine poses its own challenges.

Best regards,

Hello @jack-liuhang
Welcome. But I dont think it is challenging since fifo is not used for multi daemons listening like that. Quite sure multi daemons can access to fifo at a time, but data will not be duplicated, hence this pointing out that only 1 daemon should be there on listening side.
The fix will focus on the current daemon, meaning new daemon will be blocked and cannot initialized due to fifo in use.
Any concern kindly raise for discussion.
Thanks

Hello @jack-liuhang
The fix is available in #664 , could you kindly check that issue can be fixed on your side?
For the mechanism I will confirm with other maintainers to see if it is appropriate, since it seems make sense now for FIFO to just be used by only one daemon.
Thank you

Maybe another question will raise, and I have mentioned in the MR
thanks so much,