Sometimes when a volume is mounted and the system is shutdown, VC doesn't properly delete the ".VeraCrypt-lock-username" file and on the next boot it has to be deleted manually so that VC can start.
Can you look into this please? Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This probably happens because Linux is killing the VeraCrypt process before it has time to finish the cleanup code. In the code, priority if put on dismounting the volumes properly and in some cases this may take some time to finish and so Linux may decide to kill the VeraCrypt process.
I'll see if it is possible to implement a better approach for the lock handling.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-14
Thanks Mounir, I appreciate it. I don't mind it that much but it will benefit other newbies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue happen when VeraCrypt doesn't close cleanly upon shutdown/reboot and on the next startup another process is running with the same PID as VeraCrypt before shutdow/reboot: the lock file on the disk contains the PID of the old instance of VeraCrypt (before new start) and the check is done by seeing if a process is running with the same PID.
I fixed this by validating that VeraCrypt is indeed running through the use of a dedicate PIPE that already existed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has this issue also been resolved in the Linux version? I am getting this "VeraCrypt is already running" message even when I did dismount all drives before exiting previously. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sometimes when a volume is mounted and the system is shutdown, VC doesn't properly delete the ".VeraCrypt-lock-username" file and on the next boot it has to be deleted manually so that VC can start.
Can you look into this please? Cheers
This probably happens because Linux is killing the VeraCrypt process before it has time to finish the cleanup code. In the code, priority if put on dismounting the volumes properly and in some cases this may take some time to finish and so Linux may decide to kill the VeraCrypt process.
I'll see if it is possible to implement a better approach for the lock handling.
Thanks Mounir, I appreciate it. I don't mind it that much but it will benefit other newbies.
I have committed a fix for this issue: https://sourceforge.net/p/veracrypt/code/ci/483efd5913e32d15341624191b7c695a7b46b3a0/
The issue happen when VeraCrypt doesn't close cleanly upon shutdown/reboot and on the next startup another process is running with the same PID as VeraCrypt before shutdow/reboot: the lock file on the disk contains the PID of the old instance of VeraCrypt (before new start) and the check is done by seeing if a process is running with the same PID.
I fixed this by validating that VeraCrypt is indeed running through the use of a dedicate PIPE that already existed.
Has this issue also been resolved in the Linux version? I am getting this "VeraCrypt is already running" message even when I did dismount all drives before exiting previously. Thanks.