Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QSettings on closeEvent and 'setNativeLocks failed: Resource temporarily unavailable'
QtWS25 Last Chance

QSettings on closeEvent and 'setNativeLocks failed: Resource temporarily unavailable'

Scheduled Pinned Locked Moved General and Desktop
qsettingscloseeventlinuxredhat 6qt5.4
5 Posts 4 Posters 4.7k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    atLeast4Characters
    wrote on last edited by
    #1

    I'm using Redhat 6.6 with Qt5.4.0. Under Qt4 I often put a QSettings call in my MainWindow's closeEvent handler to save window state and geometry. Under Qt5 this seems to be causing issues I don't understand. One issue is that I see 'setNativeLocks failed: Resource temporarily unavailable' output on the console at close. This seems to be preventing some application from exiting cleanly. The following code outputs the string, but does appear to exit properly. I haven't managed to replicate the behavior of my application that doesn't exit in a sample application. On OSX I do not see the issue.

    MainWindow.h:

    #include <QtWidgets>
    
    class MainWindow : public QMainWindow
    {
        Q_OBJECT;
    
    public:
        MainWindow();
        virtual void closeEvent(QCloseEvent *e);
    };
    

    MainWindow.cpp:

    #include "MainWindow.h"
    
    MainWindow::MainWindow()
    {
        if (qApp->applicationName().size())
        {
            QString windowTitle = qApp->applicationName();
    
            if (qApp->applicationVersion().size())
                windowTitle += " " + qApp->applicationVersion();
    
            setWindowTitle(windowTitle);
        }
    
        setObjectName(windowTitle());
    
        QSettings settings;
        restoreState(settings.value("MainWindow/State", saveState()).toByteArray());
        restoreGeometry(settings.value("MainWindow/Geometry", saveGeometry()).toByteArray());
    }
    
    void MainWindow::closeEvent(QCloseEvent *e)
    {
        QSettings settings;
        settings.setValue("MainWindow/State", saveState());
        settings.setValue("MainWindow/Geometry", saveGeometry());
        e->accept();
    }
    
    int main(int argc, char *argv[])
    {
        QApplication app(argc, argv);
        app.setApplicationName("Simple");
        app.setApplicationVersion("0.0");
        app.setOrganizationName("Noname");
        app.setOrganizationDomain("noname.example.com");
    
        MainWindow window;
        window.show();
    
        return app.exec();
    }
    
    A 1 Reply Last reply
    0
    • A atLeast4Characters

      I'm using Redhat 6.6 with Qt5.4.0. Under Qt4 I often put a QSettings call in my MainWindow's closeEvent handler to save window state and geometry. Under Qt5 this seems to be causing issues I don't understand. One issue is that I see 'setNativeLocks failed: Resource temporarily unavailable' output on the console at close. This seems to be preventing some application from exiting cleanly. The following code outputs the string, but does appear to exit properly. I haven't managed to replicate the behavior of my application that doesn't exit in a sample application. On OSX I do not see the issue.

      MainWindow.h:

      #include <QtWidgets>
      
      class MainWindow : public QMainWindow
      {
          Q_OBJECT;
      
      public:
          MainWindow();
          virtual void closeEvent(QCloseEvent *e);
      };
      

      MainWindow.cpp:

      #include "MainWindow.h"
      
      MainWindow::MainWindow()
      {
          if (qApp->applicationName().size())
          {
              QString windowTitle = qApp->applicationName();
      
              if (qApp->applicationVersion().size())
                  windowTitle += " " + qApp->applicationVersion();
      
              setWindowTitle(windowTitle);
          }
      
          setObjectName(windowTitle());
      
          QSettings settings;
          restoreState(settings.value("MainWindow/State", saveState()).toByteArray());
          restoreGeometry(settings.value("MainWindow/Geometry", saveGeometry()).toByteArray());
      }
      
      void MainWindow::closeEvent(QCloseEvent *e)
      {
          QSettings settings;
          settings.setValue("MainWindow/State", saveState());
          settings.setValue("MainWindow/Geometry", saveGeometry());
          e->accept();
      }
      
      int main(int argc, char *argv[])
      {
          QApplication app(argc, argv);
          app.setApplicationName("Simple");
          app.setApplicationVersion("0.0");
          app.setOrganizationName("Noname");
          app.setOrganizationDomain("noname.example.com");
      
          MainWindow window;
          window.show();
      
          return app.exec();
      }
      
      A Offline
      A Offline
      Alchete
      wrote on last edited by
      #2

      @atLeast4Characters

      I'm facing the exact same issue (with CentOS 6.2 and Qt 5.4.1).

      Did you ever manage to solve this?

      Or does anyone else have a solution?

      1 Reply Last reply
      0
      • Chris KawaC Offline
        Chris KawaC Offline
        Chris Kawa
        Lifetime Qt Champion
        wrote on last edited by
        #3

        Not exactly the same issue but by looking at this thread it might be a case of a stale lock file. Check the /var/lock/ directory as suggested there.

        1 Reply Last reply
        0
        • A Offline
          A Offline
          Alchete
          wrote on last edited by
          #4

          Thanks Chris. I tried rebooting the workstation, to no avail.

          Unfortunately, after digging through the Qt bug reports, I found this one which accurately describes the issue:

          https://bugreports.qt.io/browse/QTBUG-43454

          QSettings now (5.4+) uses QLockFile and it fails for NFS-connected systems. I'm surprised more people aren't running into this, especially in corporate environments...

          1 Reply Last reply
          0
          • H Offline
            H Offline
            HardyH
            wrote on last edited by
            #5

            Well ... someone in a corporate environment here [1] really suffering from this bug after upgrading to openSUSE Leap 42.1 which ships with Plasma 5. Considering openSUSE Leap and SUSE Linux Enterprise Server are now so tightly coupled in development I suspect this bug will start to affect more and more users.

            I would like to add that sometimes it's not just an extra warning, but actually blocks the UI.

            Running strace on kwrite opening a file from a NFSv4 drive results in the following messages:

            open("/NFSv4mount/home/user/.config/kwriterc.lock", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 9
            fcntl(9, F_SETFD, FD_CLOEXEC) = 0
            flock(9, LOCK_EX|LOCK_NB) = 0
            fcntl(9, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EAGAIN (Resource temporarily unavailable)
            write(2, "setNativeLocks failed: Resource "..., 56setNativeLocks failed: Resource temporarily unavailable
            ) = 56
            write(9, "24895\nkwrite\nPC-123456\n", 23) = 23
            open("/NFSv4mount/home/user/.config/kwriterc.lock", O_RDONLY|O_CLOEXEC) = 12
            fcntl(12, F_SETFD, FD_CLOEXEC) = 0
            fstat(12, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
            fstat(12, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
            read(12, "29337\nkwrite\nPC-123456\n", 16384) = 23
            read(12, "", 16361) = 0
            close(12) = 0
            uname({sysname="Linux", nodename="PC-123456", ...}) = 0
            kill(29337, SIG_0) = -1 ESRCH (No such process)
            open("/NFSv4mount/home/user/.config/kwriterc.lock", O_WRONLY|O_CLOEXEC) = 12
            fcntl(12, F_SETFD, FD_CLOEXEC) = 0
            flock(12, LOCK_EX|LOCK_NB) = 0
            fcntl(12, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EAGAIN (Resource temporarily unavailable)
            close(12) = 0
            close(9) = 0
            unlink("/NFSv4mount/home/user/.config/kwriterc.lock") = 0
            nanosleep({6, 400000000}, 0x7ffd3a249730) = 0

            (the nanosleep timer just increases, meanwhile the kwrite window stays "blank" (actually whatever the background of the window was when it was started)).

            If I intervene and remove this file kwrite immediately returns and shows the file. And in subsequent starts the file opens immediately.

            Perhaps a workaround would be to move my .config directory back to local disk and place a symlink in my home folder to this on disk location.

            Relevant bug report:
            https://bugreports.qt.io/browse/QTBUG-43454

            ===
            My corporate environment, for those interested:
            [1] Using sssd.conf: services = nss, pam, autofs
            Using ldap to login, automount to mount a NFSv4 Kerberized mount.

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved