Bug 1551678

> lockfile“ is always remains in /tmp directory, but should be deleted.

This sounds more like a bug in qtlockedfile that's used in qtsingleapplication used in qupzilla.

Taking package to get rid of orphan.

Is the file in /tmp still there after you reboot?

As /tmp is normally mounted as tmpfs, all files will be dropped after shutdown.

Actually, Kevin Kofler which is one from the packages maintainers (i thing), asked me to open a bug about that here. 
Ref: https://bugs.kde.org/show_bug.cgi?id=391370#c9

So if you thing that i'm wrong, just close the issue please!

Yes, I am the maintainer of QupZilla in Fedora, and have submitted a review request for the new Falkon.

It is true that /tmp is a tmpfs by default on Fedora and so will be wiped on a reboot, unless the user disables the tmpfs mount (which makes sense on machines with little RAM). But IMHO that is not a valid excuse for letting trash accumulate in it.

Actually i noticed that this file is an extra file and probably should not be created. In fact, it has a different name.
Here is an example:

'/tmp/qtsingleapp-QupZil-b880-3e8' 
'/tmp/qtsingleapp-QupZil-b880-3e8-lockfile' 
'/tmp/qtsingleapp-qupzil-bd40-3e8-lockfile'

A possible workaround could be to write the files in a tmpfs that is accessible for the actual user only, maybe use $XDG_CACHE_HOME or XDG_RUNTIME_DIR [1]. At least, the user logs out from the session and it would magically let drop the temporary stuff.

Also, we could run into a security issue with those files, /tmp can be accessed from everyone.

[1] https://wiki.archlinux.org/index.php/XDG_Base_Directory_support#User_directories

Some related interesting discussion about using XDG:
https://news.ycombinator.com/item?id=4331969

The problem here is why the 3rd file is being created.

The following lines are determining the file name:
    socketName = QLatin1String("qtsingleapp-") + prefix
                 + QLatin1Char('-') + QString::number(idNum, 16);

This: "QString::number(idNum, 16)" goes ===> "b880"

so where the "bd40" comes from!!!!???

(In reply to Damage.inc from comment #8)
… 
> so where the "bd40" comes from!!!!???

Please ask upstream. We do the packaging only, upstream writes the code.
http://t-sato.in.coocan.jp/xvkbd/#author

So I think I see where the issue is. First, we construct the QtSingleApplication with the default appId, which calls sysInit() once. Then, setAppId is called, which calls sysInit(appId) and creates a new socket, without deleting the old one first.

I would blame the modifications from QupZilla/Falkon adding that setAppId method. But the bundled version in QupZilla/Falkon has that too, so I don't see why you are not seeing this bug with that version.

(In reply to Kevin Kofler from comment #10)
…
> I would blame the modifications from QupZilla/Falkon adding that setAppId
> method. But the bundled version in QupZilla/Falkon has that too, so I don't
> see why you are not seeing this bug with that version.

This patch was applied because of unbundling.

https://src.fedoraproject.org/rpms/qupzilla/c/40782abac81326dfb8704c5dd559cfd98a5983fb?branch=master

I know, which is why I wrote "the modifications from QupZilla/Falkon", it is clear that they come from there.

Does Falkon still need the mentioned patch? If yes, I would tend to say we should try to poke upstream to coordinate the missing functionality to get moved into the appropriate library.

Wrong/useless link for upstream given in comment #9, sorry.

Maybe replace implementation with the alternative of itay-grudev?
https://github.com/itay-grudev/SingleApplication

As far as I can see, this solution uses an unique socket to connect to and ask for its server instance.

Falkon still uses the mentioned patch, yes.

Given that nobody understands why this bug happens and that it reportedly does not happen with the bundled version for unknown reasons, I think it may just be best to switch to the bundled copy and drop the patch from the system library. I used to be strictly against bundling, but the Fedora policies have been lightened and, in the end, shipping reliable software is most important.

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Can we close here with WONTFIX?

Friendly reminder.

I do not mind it to be closed, thanks!

As there's a workaround available by placing the temporary file into tmpfs, see below for explanation, I think it's better to close with WORKSFORME.

Falkon upstream now (as of Falkon 3.1.0) patched their QtSingleApplication to use D-Bus instead of lock files. I am simply going to drop the system-qtsingleapplication patch.