admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

case 4694 - standalone setup stops a running embedded PostgreSQL first

Browse Source 
The 8.2.4 and older launchers left PostgreSQL running after the in-app
shutdown, so every standalone upgrade stopped at "files in use" and could not
close it. PrepareToInstall and uninstall now run the installed pg_ctl stop.
Changelog; BUILD.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
John Cardinal
2026-10-25 21:45:39 -07:00
parent 7959ad9cec
commit 450acc5ef7
4 changed files with 24 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
devdocs/build/BUILD.md
View File

@@ -95,7 +95,7 @@ customer portal docs).
### Windows installers
- **Standalone** (`standalone.iss`): self-contained server, launcher, embedded PostgreSQL, empty database template, desktop shortcut to the launcher. App in `{autopf}\ayanova`; data in `{commonappdata}\ayanova\database`; logs in `{commonappdata}\ayanova\logs`. The launcher starts PostgreSQL, starts the server, opens the browser at the login page and waits.
- **Standalone** (`standalone.iss`): self-contained server, launcher, embedded PostgreSQL, empty database template, desktop shortcut to the launcher. App in `{autopf}\ayanova`; data in `{commonappdata}\ayanova\database`; logs in `{commonappdata}\ayanova\logs`. The launcher starts PostgreSQL, starts the server, opens the browser at the login page and waits; when the server exits or its window is closed it stops PostgreSQL with `pg_ctl stop` (case 4694). Setup and uninstall also stop a running embedded PostgreSQL first (8.2.4 and older launchers left it running, which blocked upgrades with "files in use"). `postgres-standalone\bin` includes the Visual C++ runtime DLLs PostgreSQL needs (`msvcp140.dll`, `vcruntime140.dll`, `vcruntime140_1.dll`, 14.44.35211.0, Microsoft-signed, app-local; case 4695): Windows Update never updates app-local copies, so replace them when PostgreSQL is updated.
- **LAN** (`lan.iss`): framework-dependent server plus network config. No PostgreSQL. Prompts the user to download the ASP.NET Core Hosting Bundle and PostgreSQL.
### QBI (separate)

4
devdocs/modernization/NET10-PORT.md
View File

@@ -206,7 +206,7 @@ John's "next release" cases for AyaNova (exported 2026-10-24). Each is its own s
| 4692 | SuperUser can be deleted | 00. **Done** (`UserBiz.ValidateCanDelete` refuses user 1 with 2004 before any other check; the integration test `UserWithActivityShouldNotBeDeleteable`, which deleted SuperUser on a database where it had no related records and so was excluded from every run, is now `SuperUserShouldNotBeDeleteable` and runs with the rest: full suite = baseline, SuperUser still logs in afterwards; changelog) |
| 4693 | FormFieldReference start-up race | 00. **Done** (both lazily built lists, `FormFieldReferenceList` and `FormFieldKeys`, are built in a local and published when complete, fields volatile; three restarts each followed at once by the full suite: baseline every time, no "is not valid" in the log) |
| 4654 | General notification delivers at most once per 12 hours (circuit breaker) | 00. **Done** (direct messages are general notifications with no object, so the 12-hour repeat check in `CoreJobNotify` (case 3917, keyed on subscription and object) dropped every message to a user after the first; for general notifications the check now applies only to the job's own delivery error messages (`DELIVERY_ERROR_NAME`, "Error"); integration test `DirectMessage_SendAndDelete` un-skipped and now sends two messages: before, only the first arrived; after, both; full suite = baseline; changelog) |
| 4694 | Standalone launcher not shutting down PostgreSQL (raven-launcher) | 1 |
| 4694 | Standalone launcher not shutting down PostgreSQL (raven-launcher) | 1. **Done** (launcher: `pg_ctl stop -m fast -w` when the server exits, replacing the `StandardInput.Close()` that threw, and on window close (SIGHUP/CTRL_CLOSE); `standalone.iss`: `PrepareToInstall` and uninstall stop a running embedded PostgreSQL with the installed `pg_ctl`. Sandbox: 7 `postgres` processes left running as by 8.2.4, then the upgrade showed no "files in use" page and stopped them; Shut down server and closing the window each left no `postgres`. Note: closing the window or Ctrl+C already ended PostgreSQL in 8.2.4 (same console); only the in-app shutdown left it) |
| 4695 | Shipping the Visual C++ runtime DLLs with the standalone install | 1 |
| 4696 | JWT secret missing from the standalone config.json | 1. Resolved by 4711's server change; confirm on a fresh standalone install |
| 4697 | Relative date filters using the server's time zone | 1 |
@@ -261,7 +261,7 @@ Found during the port, out of scope. One line each.
- `License.DoFetchAsync` (`License.cs:629-661`) rethrows at `x == 3`, so the fifth server (Sockeye) is never tried, and it can return `null` to a caller that dereferences it
- Stray `raven-client\ayanova\cypress.json`: the Cypress suite lives in `raven-test\e2e`
- **Race, affects production after every restart:** `FormFieldReference.FormFieldReferenceList` (`biz/FormFieldReference.cs:57-59`) builds a static dictionary lazily with no lock, assigning it before filling it. A concurrent first request sees it half-built and throws `FormFieldReferenceList: <type> is not valid`. Seen twice on .NET 10, each time on the first form-field use after boot: `VendorCrud.CRUD`, then `FormCustom.FormCustomUpdate`. Fix: build the dictionary fully before publishing it (`Lazy<T>` or a static initialiser). Pre-existing, not a port change. John's decision: its own case, fixed with the other cases going into this release, not under the port. **Fixed in case 4693 (2026-10-24)**
- `raven-launcher` `Program.cs:98` calls `PGProcess.StandardInput.Close()` but standard input was never redirected, so it throws `InvalidOperationException` at shutdown: the "Postgres shut down" step never runs and the launcher exits with an error when the server stops. Postgres was started detached by `pg_ctl start`, so it probably stays running. Pre-existing; candidate for its own case. **Confirmed in the Sandbox test (8.2.4 and 8.3.0):** after "Shut down server" the launcher crashes with exactly this exception and 7 `postgres` processes stay running. Every standalone upgrade then stops at Setup's "files in use" page listing PostgreSQL Server, and "automatically close the applications" fails ("Setup was unable to automatically close all applications"): the customer must end the processes or restart Windows first. One-line fix (stop PostgreSQL with `pg_ctl stop` instead of writing to its standard input). **John, 2026-10-23: own case, fixed with the "next release" cases before 8.3.0**
- **Fixed in case 4694.** `raven-launcher` `Program.cs:98` calls `PGProcess.StandardInput.Close()` but standard input was never redirected, so it throws `InvalidOperationException` at shutdown: the "Postgres shut down" step never runs and the launcher exits with an error when the server stops. Postgres was started detached by `pg_ctl start`, so it probably stays running. Pre-existing; candidate for its own case. **Confirmed in the Sandbox test (8.2.4 and 8.3.0):** after "Shut down server" the launcher crashes with exactly this exception and 7 `postgres` processes stay running. Every standalone upgrade then stops at Setup's "files in use" page listing PostgreSQL Server, and "automatically close the applications" fails ("Setup was unable to automatically close all applications"): the customer must end the processes or restart Windows first. One-line fix (stop PostgreSQL with `pg_ctl stop` instead of writing to its standard input). **John, 2026-10-23: own case, fixed with the "next release" cases before 8.3.0**
- **Standalone install needs the Visual C++ runtime (pre-existing, same in 8.2.4; John, 2026-10-23: own case, fixed with the "next release" cases before 8.3.0):** the bundled PostgreSQL (`local-postgres\bin\pg_ctl.exe`, `postgres.exe`) needs `VCRUNTIME140.dll`, which neither the installer nor `local-postgres` provides. A Windows without it (a new PC, Windows Sandbox) shows "pg_ctl.exe - System Error: VCRUNTIME140.dll was not found" and AyaNova never starts. Confirmed fix: copying `vcruntime140.dll`, `vcruntime140_1.dll` and `msvcp140.dll` (x64, 14.44) into `local-postgres\bin` made PostgreSQL start. Ship those three in `dist\win-x64\postgres-standalone\bin` (app-local, allowed by Microsoft's redistribution terms) rather than running `vc_redist.x64.exe` (it crashed Windows Sandbox mid-install)
- Standalone `config.json` (launcher template) has no `AYANOVA_JWT_SECRET`, so every boot logs a warning and generates a random one (logins are lost on restart). Pre-existing; noted from the Sandbox test logs. **John, 2026-10-23: own case, fixed with the "next release" cases before 8.3.0**
- Restore manual (`ops-restore.md`) covers only the default `postgres` setup. A customer running AyaNova under a dedicated, non-superuser role who restores as `postgres` without `--role` ends up with tables owned by `postgres` and a failed integrity check at boot (found in the section 4 role test). Add a short note: `pg_restore --no-owner --no-privileges --role=<role>`. Pre-existing; after the release

20
dist/install/windows/x64/standalone.iss vendored
View File

@@ -87,8 +87,28 @@ Filename: "{sys}\icacls.exe"; Parameters: """{app}"" /remove:g *S-1-5-32-545 /T
Filename: "{app}\launcher\ayanova-launcher.exe"; Description: "{cm:LaunchProgram,{#StringChange(MyAppName, '&', '&&')}}"; Flags: nowait postinstall skipifsilent
[Code]
// case 4694: the launcher of 8.2.4 and older left the local PostgreSQL server running when AyaNova was shut down, so
// its files are in use; stop it (if running) before installing over it or uninstalling
procedure StopLocalPostgres();
var
PgCtl: String;
ResultCode: Integer;
begin
PgCtl := ExpandConstant('{app}\local-postgres\bin\pg_ctl.exe');
if FileExists(PgCtl) and DirExists(ExpandConstant('{commonappdata}\ayanova\database')) then
Exec(PgCtl, 'stop -D "' + ExpandConstant('{commonappdata}\ayanova\database') + '" -m fast -w', ExtractFileDir(PgCtl), SW_HIDE, ewWaitUntilTerminated, ResultCode);
end;
function PrepareToInstall(var NeedsRestart: Boolean): String;
begin
StopLocalPostgres();
Result := '';
end;
procedure CurUninstallStepChanged(CurUninstallStep: TUninstallStep);
begin
if CurUninstallStep = usUninstall then
StopLocalPostgres();
if CurUninstallStep = usPostUninstall then
begin
if MsgBox('Do you want to delete all AyaNova database, attachment and log files?', mbConfirmation, MB_YESNO or MB_DEFBUTTON2) = IDYES then

1
docs/8.0/ayanova/docs/changelog.md
View File

@@ -43,6 +43,7 @@ IN PROGRESS
- Docs: updated the [Linux server](ops-install-linux-server.md), [Linux desktop](ops-install-linux-desktop.md), [Windows local network](ops-install-windows-lan.md) and [Windows IIS](ops-install-windows-iis.md) installation and upgrade instructions for .NET 10 and Ubuntu 24.04 / 26.04.
- Docs: updated the database password guidance in the installation and [backup](ops-form-backup.md) documentation.
- Windows IIS: reports, including reports attached to customer notifications, now render under IIS with any site bindings, HTTPS included, without the [report rendering API URL override](ops-config-report-rendering-api-url-override.md) setting. See [report rendering under IIS](ops-install-windows-iis.md#report-rendering-under-iis).
- Windows single user: the database server now shuts down when AyaNova is shut down, so installing an upgrade no longer stops at a "files in use" page. The installer also shuts down a database server left running by an earlier version.
- Windows: the installers no longer give all local users write access to the AyaNova program folder; only administrators can change files there. Upgrading removes the earlier write access.
- Windows: the local network installer and the [local network](ops-install-windows-lan.md) and [IIS](ops-install-windows-iis.md) installation instructions now link to the official PostgreSQL download page (the third-party guide linked before is no longer available), and the configuration examples assume PostgreSQL 18.
- Docs: the Windows installation instructions now state that only one type of AyaNova 8 installation (single user, local network or IIS) can be on a computer at a time.