# Applications crash during pkg upgrade



## mzs47 (Jul 4, 2015)

I noticed on FreeBSD that when I do `pkg upgrade` some of the applications which are currently running just crash.
For example today I ran the upgrade:


```
freebsd64_10# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%  944 B  0.9kB/s  00:01 
Fetching packagesite.txz: 100%  5 MiB 359.4kB/s  00:15 
Processing entries: 100%
FreeBSD repository update completed. 24266 packages processed.
Checking for upgrades (279 candidates): 100%
Processing candidates (279 candidates): 100%
The following 11 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
   wesnoth: 1.12.2,1 -> 1.12.4,1
   vim: 7.4.752 -> 7.4.764
   pciids: 20150615 -> 20150701
   openldap-client: 2.4.40_1 -> 2.4.41
   netpbm: 10.35.94_1 -> 10.35.96
   libxml2: 2.9.2_2 -> 2.9.2_3
   libdvdread: 5.0.2 -> 5.0.3
   libXpm: 3.5.11_3 -> 3.5.11_4
   jsoncpp: 0.6.0.r2_1 -> 0.6.0.r2_2
   ansible: 1.9.1 -> 1.9.2

Installed packages to be REINSTALLED:
   speech-dispatcher-0.8.3 (options changed)

The process will require 76 KiB more space.
358 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching wesnoth-1.12.4,1.txz: 100%  347 MiB  97.6kB/s 01:02:08 
Fetching vim-7.4.764.txz: 100%  6 MiB 106.6kB/s  00:59 
Fetching speech-dispatcher-0.8.3.txz: 100%  345 KiB 117.9kB/s  00:03 
Fetching pciids-20150701.txz: 100%  189 KiB 193.2kB/s  00:01 
Fetching openldap-client-2.4.41.txz: 100%  1 MiB 259.1kB/s  00:04 
Fetching netpbm-10.35.96.txz: 100%  1000 Ki 255.9kB/s  00:04 
Fetching libxml2-2.9.2_3.txz: 100%  788 KiB 115.3kB/s  00:07 
Fetching libdvdread-5.0.3.txz: 100%  109 KiB 111.5kB/s  00:01 
Fetching libXpm-3.5.11_4.txz: 100%  68 KiB  70.1kB/s  00:01 
Fetching jsoncpp-0.6.0.r2_2.txz: 100%  123 KiB 125.8kB/s  00:01 
Fetching ansible-1.9.2.txz: 100%  1 MiB 124.3kB/s  00:10 
Checking integrity... done (0 conflicting)
```

I had www/seamonkey open while I did this and it crashed.
Reminds me of the Windows days when I was asked to close all running instances of an application.

On Debian/Ubuntu I have not noticed this, though sometimes the applications have misbehaved.
Why does this happen?


----------



## junovitch@ (Jul 4, 2015)

On Windows, closing running instances of an application is a requirement because of how the OS handles locking files.  Some actions simply cannot be done without closing applications or restarting the system.  On various *nix platforms the file descriptor to the old deleted file will remain valid until the application using it stops.  That is why you should be able to update a running system with minimal impact.  That works for simple applications but in practice some applications may need to get something from disk at an inopportune time and that may have been while the packages were being updated.  The rolling release model of FreeBSD ports make it more likely that grabbing some library or file from disk may cause bad behaviour then the locked package versions that Debian/Ubuntu may use.


----------

