GNUstep directory keeps being created when removed

In my home directory there's a directory called “GNUstep”. As I don't use GNUstep I want to remove this directory, but it keeps being created when I do so:

$ tree GNUstep
GNUstep
└── Defaults
1 directory, 0 files
$ rm -rf GNUstep
$ tree GNUstep # executed after a few seconds
GNUstep
└── Defaults
1 directory, 0 files

I already removed every related package so that apt search gnustep | grep installed now doesn't show anything. I also did apt autoremove without any avail. I use Lubuntu 16.04.

How can I determine which process creates the directory every time I removed it, and how can I prevent it from doing so?

This is not a duplicate of:

• What is this GNUstep folder? – Other than “just delete it” (which I did) it contains no information about how to permanently remove the directory.
• How to uninstall GNUStep? – I already did that and it didn't solve the problem.

This suggests:

As a workaround you can change the value of GNUSTEP_USER_DEFAULTS_DIR in /etc/GNUstep/GNUstep.conf file.

Unfortunately there's no such file on my machine, not even /etc/GNUstep exists.

Solution 1:

TL;DR: In this case, the packages were uninstalled by a still-running instance of a program continued to re-create the directory. Examining the output of ps x revealed what program it was.

There are two major considerations here:

1. Did you remove everything you intended to remove?
2. Is it still running even though it has been uninstalled and the files deleted? (That can happen.)

1. Finding what was removed and what you still have, and removing packages.

It is useful to keep track of what actions you have taken (such as what commands you have run) to remove packages, as well as what packages have been removed. But even if not, you can look in the log files /var/log/apt/term.log, /var/log/apt/history.log, and /var/log/dpkg.log. Especially for recent package removals, it's easy to see what was removed. If you performed the removals by running commands in your terminal then they should also be in your shell's history, which in Bash you can examine with the history command (run help history for details), though that will just show what you commands you ran, not their effects.

To search for installed packages that contain a particular word, like gnustep, I recommend using:

apt list --installed '*gnustep*'

(When the word is something other than gnustep, replace gnustep with it.)

Note that, although apt's list action supports * as a globbing character, the remove and purge actions do not. Instead they treat it as a metacharacter in a regular expression (much as grep does), and people have sometimes removed vastly more packages than they intended and had to repair their systems. It's usually best to just pass the names of the specific packages you want to remove. But if, for example, you needed to remove all packages whose names begin with libgnustep, then you could run:

sudo apt remove ^libgnustep

(To remove conffiles too, you could use purge in place of remove.)

2. Uninstalled programs and libraries may continue running even once deleted.

Unless the removal scripts that are run when you uninstall a package include commands to terminate any running instances of the program(s) it provides, which is rare except for those that provide background services, or to terminate other programs that are using the libraries it provides, which is unheard of, the software provided by a package you have uninstalled may still be running even after the files have been undeleted.

A file may have one or more hard links, i.e., filenames. (Hard links should not be confused with symlinks.) When all of them have been removed, the file is actually deleted: its inode entry is removed and the storage locations on disk that stored the file's data are permitted to be reused. Except if the file is currently open. Then the file is preserved until it has been closed, which happens when the programs using it deliberately close the file or when they quit. Similarly, if the file you have removed is a program, the program will continue to run and the file will be preserved on disk until it has exited.

Therefore, when you uninstall a package that provides a program but the program is running, deleting the program does not automatically quit the program nor necessarily interfere with its operation (though it may, if it later opens other files it expects to be present). And when you uninstall a package that provides a library but some program is still using that library, the library temporarily continues to exist on disk and the program using it continues to run.

Rebooting is sufficient to cause the files to be removed because running processes don't survive a reboot. Logging out and back in may actually be insufficient, though it is often enough. However, if you must not reboot, or prefer not to, then you can try to figure out what program is running and exit it. In many cases, including the situation you experienced, that's the best way to proceed because it is faster and almost as easy as rebooting. But if you have trouble finding the process or otherwise don't want to bother, a reboot will fix it.

As a GNUstep program runs, it may read from and write to ~/GNUstep, and it may re-create it if it finds that it is not there. Although you could try to grep for specific GNUstep-related text in your list of running processes (see below), I suggest taking a more general approach:

1. Examine the output of ps x. You could also use the a flag--ps ax--to show processes by all users, but I suggest omitting it for starters because the process probably does belong to you so listing everything would likely only give you a bigger haystack. Since the full command line is sometimes useful, I suggest running ps x --columns=100000. Or just run ps | cat, because ps doesn't truncate when its output isn't a terminal. This is one of several situations where "useless use of cat" isn't so useless after all.

   (You're unlikely to actually get lines that are a hundred thousand characters long--that's just a big number chosen to ensure lines don't get truncated. Going up by another order of magnitude makes ps say fix bigness error so that's why I've picked 100000.)

2. Check pstree. This shows all processes by default, and it visually shows their parent-child relationships. This is useful if it turned out that the process belonged to another user after all, or if it belonged to you but you happened to miss it when you looked through the output of ps.

When you ran that ps command (readers: this answer was written after the problem was solved based on a comment), you found that the still-running program was:

/usr/lib/GNUstep/Applications/GSSpeechServer.app/GSSpeechSer‌​ver

The methods I described above aren't GNUstep specific--except in the sense that your running GNUstep applications are likely running as you and not as another user like root, but that's a common situation and not really specific to GNUstep. However, the typical pathname of a GNUstep program contains a .app directory since they are usually provided as .app containers. Even though the file is removed, ps still shows the name by which it was invoked, which often is an absolute path.

Thus, users who are looking for a GNUstep program, especially if they are running very many other programs and don't want to inspect the output of ps x, can try to find it by running:

ps x | grep '[.]app/'

(. in a regular expression matches any character. One way to match a literal dot is [.], and while there are other ways, I've picked that one because it causes your grep command line not to contain .app and thus not to be included spuriously in your results.)