@metabase/rde 0.1.11 → 0.1.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +30 -23
- package/dist/cli.mjs +2484 -1712
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -35,19 +35,22 @@ The wizard shows its checklist first (`✓` done, `○` to do, `–` not applica
|
|
|
35
35
|
○ Start Metabase
|
|
36
36
|
○ Create the admin user
|
|
37
37
|
○ Connect the Metabase CLI
|
|
38
|
+
○ Enable transforms
|
|
38
39
|
○ Connect a sample database
|
|
39
40
|
○ Activate your license
|
|
40
|
-
○ Connect your databases
|
|
41
41
|
– Connect a git repository
|
|
42
|
+
○ Connect your databases
|
|
42
43
|
○ Summary
|
|
43
44
|
│
|
|
44
45
|
● Running npm install -g @metabase/cli@alpha-release-65-integration-branch
|
|
45
46
|
```
|
|
46
47
|
|
|
47
|
-
The steps up to the license run without a question, save one: `mb` is installed with the package manager that installed `rde`, the skill goes to the coding agents you pick from the ones found on the machine (at a terminal; without one, to every agent found), Metabase runs in Docker when Docker is there (the jar with your Java otherwise), on the first free port from
|
|
48
|
+
The steps up to the license run without a question, save one: `mb` is installed with the package manager that installed `rde`, the skill goes to the coding agents you pick from the ones found on the machine (at a terminal; without one, to every agent found), Metabase runs in Docker when Docker is there (the jar with your Java otherwise), on the first free port from 23000 up that no other container or instance claims, with an admin user whose password is generated and kept in `~/.rde`, `mb` is logged in under its `default` profile (the one question here comes when `default` already points at another Metabase), and a Postgres sample database comes up in a second container, connected to Metabase as a place transforms can write. Each of those choices is printed as it is made and can be overridden with a flag. The prompts that remain are the license token (Enter skips it), with a license that includes remote sync where the git repository lives and which remote it uses, and your own databases (Enter skips them).
|
|
48
49
|
|
|
49
50
|
The databases step asks once. At a terminal, without `--yes` or `--skip-databases`, and while none of your own databases is connected, it lists what is connected (the sample database) and asks for a connection string: paste one and `rde` reads the engine from it (or asks which, when the string fits several, or shows the engine list when it fits none), then shows the connection for review, tests it, adds it, and offers another. Enter skips it, and the skip is remembered, so the next `rde init` does not ask again; `rde init --only databases` and `rde db add` still do. With `--yes` or without a terminal it asks nothing and the sample database stands in; `--database` connects yours ahead of time.
|
|
50
51
|
|
|
52
|
+
It runs after the git step because content imported from a repository names its databases, and Metabase only finds them by name. Every database the content names that this instance lacks becomes a stub: a placeholder with that name and no connection, which keeps the content importable and which Metabase leaves out of its own database lists. When there are stubs, the step asks for them instead of the connection string: a checklist of their names, none picked, where you pick the few you work on (a repository can name dozens, most of them someone else's or out of reach from your machine). Each one picked asks for its connection string (Enter goes to the engine list, whose last choice leaves that one unconnected), then review, test, and connect: the stub becomes the real database under the same name and id, so the content on it works and its sync starts. Picking none skips the step like Enter does. The ones left over are named at the end of the step and in the summary, and `rde db add` and `rde db list` show them until they are connected. A database named ahead of time (`--database`, an answers file, `rde db add --url --name`) whose name is a stub's connects that stub too, never a second database of the same name.
|
|
53
|
+
|
|
51
54
|
The git step reads `–` until a license with remote sync is active; it is checked again when its turn comes, so a run that activates a license connects the repository in the same pass.
|
|
52
55
|
|
|
53
56
|
| Step | What it does |
|
|
@@ -55,14 +58,15 @@ The git step reads `–` until a license with remote sync is active; it is check
|
|
|
55
58
|
| Check this machine | Platform, Node version, git, and a reachable Docker daemon or a Java 21+ runtime |
|
|
56
59
|
| Install the Metabase CLI | `@metabase/cli` (`mb`) at the `alpha-release-65-integration-branch` dist-tag, with the package manager that installed `rde` |
|
|
57
60
|
| Install the rde and data-app skills | The data-app skills (`metabase-data-app-setup`, `-routing`, `-actions`, `-semantic-layer`) from `metabase/metabase/skills#master`, then the `rde` and `rde-data-apps` skills from the `main` branch of `metabase/agent-skills` (the rde skill hands an explicit app request to `rde-data-apps`, which hands the build to the data-app skills), for the coding agents you pick at a terminal, from the ones found on this machine (Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Windsurf). When none is found, the step is skipped and says how to add the skills once an agent is installed; `rde` installs no agent. Without a terminal, or with `--yes`, every agent found gets the skills; `--agents` picks a set ahead of time (the skills are installed for them whether or not they are on the machine yet), `--skip-agents` none; `RDE_SKILL_SOURCE` installs the two rde skills from another URL or a local checkout of `metabase/agent-skills` |
|
|
58
|
-
| Install Metabase | **Docker** when it is available: pulls `metabase/metabase-enterprise-head:latest` (or `--image`) and creates the container. **Jar** otherwise, or with `--runtime jar`: downloads the latest enterprise release (or the tag or `.jar` path given as `--jar`) into `~/.rde/jars/` and runs it with your Java. Either way on port
|
|
61
|
+
| Install Metabase | **Docker** when it is available: pulls `metabase/metabase-enterprise-head:latest` (or `--image`) and creates the container. **Jar** otherwise, or with `--runtime jar`: downloads the latest enterprise release (or the tag or `.jar` path given as `--jar`) into `~/.rde/jars/` and runs it with your Java. Either way on port 23000, or the first free port above it that nothing else claims, or `--port` |
|
|
59
62
|
| Start Metabase | Starts the container or the jar and waits for `/api/health`, showing Metabase's own progress |
|
|
60
63
|
| Create the admin user | `admin@metabase.local` with a generated password that `rde credentials` shows, or your own with `--admin prompted`, see [Credentials](#credentials) |
|
|
61
64
|
| Connect the Metabase CLI | Creates an API key named `rde` and logs `mb` in with it under the profile `default`, so plain `mb` uses the instance; when `default` already points at another Metabase it asks first, see [The `mb` profile](#the-mb-profile); a key Metabase rejects is replaced |
|
|
62
|
-
|
|
|
65
|
+
| Enable transforms | Turns transforms on, unless someone already set them either way: turned off in the admin settings, they stay off on every later `rde init`, and the admin settings turn them back on |
|
|
66
|
+
| Connect a sample database | Runs Metabase's Postgres sample data (`metabase/qa-databases:postgres-sample-15`) in a container named `rde-sampledb-default` on the first free port from 25432 (or one Docker picks, when another program or a concurrent `rde init` takes that port first), and connects it as `Sample Database`. It replaces the H2 sample database Metabase would otherwise bundle, which cannot be a transform target. Needs Docker, so a jar instance on a machine without Docker has no sample database |
|
|
63
67
|
| Activate your license | Optional. Paste a token, or press Enter to skip; remote sync needs one with the `remote-sync` feature |
|
|
64
|
-
| Connect
|
|
65
|
-
| Connect a
|
|
68
|
+
| Connect a git repository | Only with a license. Initializes or reuses a repository and points Metabase's remote sync at it, with transforms included in the sync (the Transforms row under Collections to sync), and imports the content it already holds |
|
|
69
|
+
| Connect your databases | At a terminal, until you connect one of your own or skip it: pick the databases the imported content uses from a checklist, or, with none, paste a connection string (Enter skips); review, test, add; repeat. `--database` names them ahead of time; with `--yes` or without a terminal nothing is asked. `rde db add` starts from the same checklist, then the engine list, where the fields can also be filled one by one |
|
|
66
70
|
| Summary | URL, login email, the `mb` command for the instance, databases, repository, and the command that opens each detected agent |
|
|
67
71
|
|
|
68
72
|
The second run on the same machine detects every step as done and prints the summary only:
|
|
@@ -76,21 +80,22 @@ The second run on the same machine detects every step as done and prints the sum
|
|
|
76
80
|
✓ Start Metabase
|
|
77
81
|
✓ Create the admin user
|
|
78
82
|
✓ Connect the Metabase CLI
|
|
83
|
+
✓ Enable transforms
|
|
79
84
|
✓ Connect a sample database
|
|
80
85
|
– Activate your license
|
|
81
|
-
✓ Connect your databases
|
|
82
86
|
– Connect a git repository
|
|
87
|
+
✓ Connect your databases
|
|
83
88
|
○ Summary
|
|
84
89
|
│
|
|
85
90
|
◇ Your environment ─────────────────────────────────────────────────────────────────╮
|
|
86
91
|
│ │
|
|
87
|
-
│ Metabase: http://localhost:
|
|
92
|
+
│ Metabase: http://localhost:23000 │
|
|
88
93
|
│ Login: admin@metabase.local (rde credentials shows the password) │
|
|
89
94
|
│ Metabase CLI: mb <command> │
|
|
90
95
|
│ Databases: │
|
|
91
96
|
│ Sample Database (postgres, sync complete) │
|
|
92
97
|
│ warehouse (postgres, syncing; `rde status` shows when it finishes) │
|
|
93
|
-
│ Sample database: psql "postgres://metabase:metasample123@localhost:
|
|
98
|
+
│ Sample database: psql "postgres://metabase:metasample123@localhost:25432/sample" │
|
|
94
99
|
│ Remote sync: not configured (no license) │
|
|
95
100
|
│ rde skill: installed for Claude Code │
|
|
96
101
|
│ Start working: │
|
|
@@ -102,14 +107,14 @@ The second run on the same machine detects every step as done and prints the sum
|
|
|
102
107
|
└ rde init finished
|
|
103
108
|
```
|
|
104
109
|
|
|
105
|
-
Ctrl-C at any prompt stops the run; `rde init` again continues from the first step that is not done. A step that fails ends the run with exit code 1 (2 for a missing answer) and a last line naming the step and the command that resumes there: `rde init stopped at "Connect a sample database": <reason>. Resume with rde init --from sample-database.` `rde init --from license` re-runs from a step on (a later step that does not apply, such as the git step without a license that has remote sync, stays skipped), `rde init --only databases` runs one step.
|
|
110
|
+
Ctrl-C at any prompt stops the run; `rde init` again continues from the first step that is not done. A run on an instance that already exists says so first (`Resuming instance "default" (Metabase http://localhost:23000, repository /Users/you/rde-content); steps already done are skipped.`, and that `rde uninstall` comes first to start over). A flag or answers-file section for a step that does not run, because it is already done, does not apply (a license skipped before), or is left out by `--only`, is ignored with a warning naming the flag and the step and how to get it done instead: `--database ignored: "Connect your databases" is already done. Connect another with rde db add --url <connection string>.` A skip flag for a step that is already done asks nothing of it and is not warned about. A step that fails ends the run with exit code 1 (2 for a missing answer) and a last line naming the step and the command that resumes there: `rde init stopped at "Connect a sample database": <reason>. Resume with rde init --from sample-database.` `rde init --from license` re-runs from a step on (a later step that does not apply, such as the git step without a license that has remote sync, stays skipped), `rde init --only databases` runs one step.
|
|
106
111
|
|
|
107
112
|
## The sample database
|
|
108
113
|
|
|
109
|
-
Every instance gets a second container, `rde-sampledb-default`, running `metabase/qa-databases:postgres-sample-15`: the Postgres edition of Metabase's own sample data, the same tables and rows the bundled H2 sample database has (`orders`, `products`, `people`, `reviews`, `accounts`, `invoices`, `feedback`, `analytic_events`), with the user `metabase`, the password `metasample123`, and the database `sample`. `init` publishes it on `127.0.0.1` at the first free port from
|
|
114
|
+
Every instance gets a second container, `rde-sampledb-default`, running `metabase/qa-databases:postgres-sample-15`: the Postgres edition of Metabase's own sample data, the same tables and rows the bundled H2 sample database has (`orders`, `products`, `people`, `reviews`, `accounts`, `invoices`, `feedback`, `analytic_events`), with the user `metabase`, the password `metasample123`, and the database `sample`. `init` publishes it on `127.0.0.1` at the first free port from 25432 up (5432 is usually your own Postgres, and 15432 a common stand-in for it), connects it to Metabase as `Sample Database`, and sets `transforms-enabled`, so transforms have somewhere to write on the first run: the H2 sample database refuses to be a transform target, this one creates the target schema on demand. The `metabase` user is the cluster superuser, so any schema name works. Metabase is started with `MB_LOAD_SAMPLE_CONTENT=false`, so the H2 sample database and the example content built on it are never created and the Postgres one is the only `Sample Database`.
|
|
110
115
|
|
|
111
116
|
```sh
|
|
112
|
-
psql "postgres://metabase:metasample123@localhost:
|
|
117
|
+
psql "postgres://metabase:metasample123@localhost:25432/sample" # the summary and `rde status` show the port
|
|
113
118
|
```
|
|
114
119
|
|
|
115
120
|
`rde start` and `rde stop` bring the container up and down with Metabase, `rde status` shows its state and sync, `rde doctor` checks it, and `rde uninstall` removes it (with `--remove-image`, its image too). The data lives inside the container: `stop`/`start` keep it, and a container that is removed comes back with the pristine sample data on the next `rde init`. The jar runtime gets the sample database as well whenever Docker is available; on a machine without Docker the step is `–` and there is no sample database at all (the H2 one is switched off for every instance).
|
|
@@ -161,14 +166,14 @@ Docker is used whenever it is available: the image is self-contained, and the co
|
|
|
161
166
|
|
|
162
167
|
| Command | What it does |
|
|
163
168
|
| --- | --- |
|
|
164
|
-
| `rde start` | Starts the sample database and the instance, and waits until Metabase is healthy |
|
|
169
|
+
| `rde start` | Starts the sample database and the instance, and waits until Metabase is healthy; `--port <n>` moves the instance to another port first (see [The instance's port is taken](#troubleshooting)) |
|
|
165
170
|
| `rde stop` | Stops both; the data stays |
|
|
166
171
|
| `rde status` | The login email, the `mb` profile, the init checklist, whether setup is complete (or the first step `init` did not finish, with the `rde init --from` command that resumes there), runtime state, health, databases with their sync state, the sample database's container and connection string, remote sync state and the content repository's working directory (`contentRepository`); `--json` for scripts and agents (`mbProfile`, `adminEmail`, `setup`, never a secret); exit 0 whatever it reports |
|
|
167
172
|
| `rde credentials` | The Metabase URL, admin email, and password; `--json` for scripts and agents; `--api-key` for the API key alone |
|
|
168
173
|
| `rde logs` | The container's log, or the jar's `metabase.log`; `-f` keeps streaming |
|
|
169
174
|
| `rde open` | Opens the instance in the browser |
|
|
170
|
-
| `rde db add` | The database wizard: pick the engine, paste a connection string or fill the fields, review, test, add. `rde db add --url <connection string> [--name <display name>]` asks nothing: it reads the engine from the string (`--engine` for one that fits several), tests it and adds it, which is how a script or a coding agent connects a database without a terminal; `--url -` reads the string from stdin |
|
|
171
|
-
| `rde db list` | The connected databases; `--json` for scripts; a bare `rde db` does the same |
|
|
175
|
+
| `rde db add` | The database wizard: pick the stubs to connect when the content uses databases not connected yet, otherwise (or after them) pick the engine, paste a connection string or fill the fields, review, test, add. `rde db add --url <connection string> [--name <display name>]` asks nothing: it reads the engine from the string (`--engine` for one that fits several), tests it and adds it, which is how a script or a coding agent connects a database without a terminal; `--url -` reads the string from stdin; a `--name` that is a stub's connects that stub |
|
|
176
|
+
| `rde db list` | The connected databases and the stubs still waiting for a connection (`stub` in `--json`); `--json` for scripts; a bare `rde db` does the same |
|
|
172
177
|
| `rde doctor` | One table of checks with a fix hint per failure; `--fix` re-runs the init steps behind them; `--json` for scripts and the rde skill (every row's `id`, `status`, `detail`, `hint`, and `fix`: the `rde` command that repairs it, or null when you have to act); exit 1 while anything fails |
|
|
173
178
|
| `rde upgrade` | Moves the instance to a newer Metabase after backing up its data; see [Upgrading](#upgrading) |
|
|
174
179
|
| `rde uninstall` | Removes the instance, its data, and the `mb` profile; see [Resetting](#resetting) |
|
|
@@ -191,12 +196,12 @@ mb git-sync status
|
|
|
191
196
|
|
|
192
197
|
## The git repository
|
|
193
198
|
|
|
194
|
-
With a license that includes remote sync, the
|
|
199
|
+
With a license that includes remote sync, the step after the license connects a git repository. You choose where Metabase pushes, then where the working directory lives (here, another directory, or an existing repository):
|
|
195
200
|
|
|
196
201
|
- **Local remote inside `~/.rde`** (default): a bare repository at `instances/default/data/content.git`, mounted into the container and reached as `file:///rde/content.git`. No account, no token. Your working directory gets it as `origin` (or as `rde-remote` when `origin` already points elsewhere).
|
|
197
202
|
- **Hosted remote**: a GitHub, GitLab, or Bitbucket `https://` URL plus a token with read and write access. `rde` tests the connection through Metabase before saving anything, then clones the repository into the working directory (an existing repository gets the URL as `origin` instead); an empty hosted repository gets the first commit pushed to it. The token is handed to Metabase and, for the clone and that first push, to git in its environment; it never lands in the clone's config, the remote URL, or a credential helper, so a later `git pull` uses your own git credentials.
|
|
198
203
|
|
|
199
|
-
A fresh repository gets a first commit with a `README.md` and a `.gitignore` that keeps out what a data app built in it must not push: `.env`, `.env.local`, `.env.*.local`, `node_modules/`, `.vite/`, the rde skill's `.scratch/`, and `.DS_Store` (a data app's built `dist/` stays tracked, since that bundle is what Metabase serves); a `.gitignore` already there keeps its lines and gets the missing ones, and a repository that already has commits is left as it is. A repository that already holds Metabase content is imported on the spot. Afterwards:
|
|
204
|
+
A fresh repository gets a first commit with a `README.md` and a `.gitignore` that keeps out what a data app built in it must not push: `.env`, `.env.local`, `.env.*.local`, `node_modules/`, `.vite/`, the rde skill's `.scratch/`, and `.DS_Store` (a data app's built `dist/` stays tracked, since that bundle is what Metabase serves); a `.gitignore` already there keeps its lines and gets the missing ones, and a repository that already has commits is left as it is. A repository that already holds Metabase content is imported on the spot; each database it names that this instance lacks becomes a stub, which the databases step right after offers to connect. Afterwards:
|
|
200
205
|
|
|
201
206
|
```sh
|
|
202
207
|
cd <your working directory>
|
|
@@ -213,17 +218,17 @@ Every prompt can be answered ahead of time, by a flag or by a JSON answers file,
|
|
|
213
218
|
|
|
214
219
|
```sh
|
|
215
220
|
rde init --skip-license \
|
|
216
|
-
--database "postgres
|
|
221
|
+
--database "postgres://user:pass@localhost:5432/app" \
|
|
217
222
|
--git-dir ~/analytics --git-remote local
|
|
218
223
|
```
|
|
219
224
|
|
|
220
225
|
| Flag | Answers |
|
|
221
226
|
| --- | --- |
|
|
222
227
|
| `--agents claude-code,codex` / `--skip-agents` | Which agents get the skill, instead of asking at a terminal or taking the ones found on the machine |
|
|
223
|
-
| `--runtime docker\|jar`, `--image`, `--jar`, `--port` | How Metabase runs, the Docker image or the jar (`latest`, a release tag, or a `.jar` path), and the host port, instead of Docker when available, `metabase/metabase-enterprise-head:latest`, the latest release, and the first free port from
|
|
228
|
+
| `--runtime docker\|jar`, `--image`, `--jar`, `--port` | How Metabase runs, the Docker image or the jar (`latest`, a release tag, or a `.jar` path), and the host port, instead of Docker when available, `metabase/metabase-enterprise-head:latest`, the latest release, and the first free port from 23000 that nothing else claims; `--image` implies `docker` and `--jar` implies `jar`; the sample database always runs in Docker |
|
|
224
229
|
| `--admin generated\|prompted`, `--admin-email`, `--admin-password` | The admin user, `generated` unless given; an email or password implies `prompted` |
|
|
225
230
|
| `--license-token` / `--skip-license` | The license |
|
|
226
|
-
| `--database <
|
|
231
|
+
| `--database <connection string>` (repeatable) / `--skip-databases` | Your own databases, the engine read from the string; `<engine>=<connection string>` names it when the string fits several (`druid=jdbc:avatica:…`); `--skip-databases` connects none of them, and the sample database is still connected |
|
|
227
232
|
| `--git-dir`, `--git-remote local\|hosted`, `--git-url`, `--git-token` / `--skip-git` | The content repository; a remote or URL without `--git-dir` means the current directory |
|
|
228
233
|
| `--mb-profile default\|rde` | The `mb` profile when `default` already points at another Metabase; `default` (replace it) unless given |
|
|
229
234
|
| `--yes` | Every confirmation, and the recommended choice of a question (replacing `default`); skips the question about your own databases, and the sample database is still connected. A driver's toggle (SSL, an SSH tunnel) is a setting, not a confirmation, and keeps the driver's default |
|
|
@@ -296,7 +301,7 @@ Start with `rde doctor`. It checks the machine (platform, Node, git, Docker, Jav
|
|
|
296
301
|
|
|
297
302
|
```
|
|
298
303
|
✓ container rde-metabase-default stopped (metabase/metabase-enterprise-head:latest)
|
|
299
|
-
✓ port
|
|
304
|
+
✓ port 23000 is free
|
|
300
305
|
✗ health unreachable
|
|
301
306
|
→ `rde start`
|
|
302
307
|
– admin user Metabase is not healthy
|
|
@@ -325,9 +330,11 @@ Fix the items above and run rde init again
|
|
|
325
330
|
|
|
326
331
|
Start Docker (or `colima start`), or install Java, and run `rde init` again. `rde start` and `rde status` report the same condition on an existing instance. An instance that was set up with Docker keeps needing Docker: `rde doctor` marks it ✗ then, whatever Java is there.
|
|
327
332
|
|
|
328
|
-
**The instance is not on port
|
|
333
|
+
**The instance is not on port 23000.** The runtime step takes the first free port from 23000 up and says so: `Port 23000 is in use or claimed; using 23001`. rde's ports are the standard ones plus 20000 (Metabase's 3000, Postgres's 5432), a block no common local tool uses and that Docker and the kernel never pick from on their own. A port counts as claimed when any Docker container, running or stopped, from this rde home or another, is created to publish it, or when another instance of this home uses it, because that container or instance takes it back the moment it starts. `rde status` and the summary show the URL; `--port` pins a port of your choice and refuses a busy or claimed one, naming who claims it. A container that exists with a different port or image is reported with the `docker rm -f` command that clears it.
|
|
334
|
+
|
|
335
|
+
**The sample database is not on port 25432.** The same rule: `Port 25432 is in use or claimed; using 25433 for the sample database`. The summary, `rde status`, and the `psql` line carry the port that was taken, and Metabase's connection uses it too. A sample database container that was removed by hand comes back on the next `rde init` (`rde doctor` points at it); if another program took its port meanwhile, it moves to the next free one and `init` says which Metabase database still points at the old port.
|
|
329
336
|
|
|
330
|
-
**The
|
|
337
|
+
**The instance's port is taken.** While an instance is stopped, another program can take its port. `rde start` then refuses rather than talk to that program: `port 23000 is in use by another program, so Metabase cannot start on it; stop that program and run \`rde start\` again, or move this instance with \`rde start --port 23001\``, and `rde status` says `another program answers at http://localhost:23000` instead of reporting it healthy. Stopping the other program is enough when it is temporary. `rde start --port <n>` moves the instance for good: Metabase stops, the container is created again on the new port from the image it already runs (the data is in `~/.rde` and stays), the state and Metabase's site URL take the new address, and the `mb` profile follows once Metabase answers there (if that start fails, the next `rde start` finishes moving the profile). Anything outside rde that knows the old URL (a bookmark, a data app's config) needs the new one. A container whose port forward Docker lost, which happens when its start once failed on a taken port, is repaired by the next `rde start`, which says so in one line.
|
|
331
338
|
|
|
332
339
|
**The jar's Java is wrong.** The jar runtime needs Java 21 or newer and says which one it found: `Java 17.0.9 at /usr/bin/java is too old`. Point `JAVA_HOME` at a newer runtime, or put one first on `PATH`; the next `rde start` uses it. A pid file left by a reboot is recognized as stale (the pid is free, or runs something else) and ignored.
|
|
333
340
|
|