Summary:
Update the Windows code to use the normal StartupLogger.h and .cpp files.
Previously the Windows code defined its own separate StartupLogger.h file.
The class declaration looked largely like a copy of the POSIX
DaemonStartupLogger code, but most of the methods were not actually defined
anywhere. The actual functionality appears identical to the POSIX
ForegroundStartupLogger, so this code just switches to using that in most
cases.
Reviewed By: xavierd
Differential Revision: D21332570
fbshipit-source-id: 0585a38d8f37dc93459d380aa277082c35cbadfc
Summary: Moving these functions to EdenInit so we could use them on Windows. This diff doesn't change the behavior.
Reviewed By: chadaustin
Differential Revision: D16653498
fbshipit-source-id: 5cc8c2f4b12f54035fb86ae20f3274245642d032
Summary:
Update the copyright & license headers in C++ files to reflect the
relicensing to GPLv2
Reviewed By: wez
Differential Revision: D15487078
fbshipit-source-id: 19f24c933a64ecad0d3a692d0f8d2a38b4194b1d
Summary:
In dev builds I have seen the `DaemonStartupLoggerTest.crashWithNoResult()`
test sometimes fail with the message
`edenfs is still running but did not report its initialization status`
instead of the expected error `edenfs crashed with signal 9`.
It appears that when killing the child process with `SIGKILL` we can see the
pipe close before the child is actually waitable. Update the `StartupLogger`
code to sleep briefly and retry the wait a few times before giving up in this
case. This allows us to determine the child's exit status correctly in this
situation.
Reviewed By: wez
Differential Revision: D15507309
fbshipit-source-id: 1f169c3061d1b2bd4154849c5dc7249e8f8c8e0c
Summary:
I want to use fake_edenfs to test logging via EdenFS' systemd service. Make fake_edenfs and the real edenfs use similar logic to determine the log file path.
This diff should not change behavior for the real edenfs.
Reviewed By: simpkins
Differential Revision: D13424470
fbshipit-source-id: d0c2e035fdb5884dbd2d9704c7e0244d35e052f2
Summary:
When you run 'eden start' without systemd integration, edenfs writes startup logs to the terminal to let users know that stuff is happening:
```
$ eden start
Starting edenfs (dev build), pid 2792025
Opening local RocksDB store...
Opened RocksDB store in 0.95 seconds.
Remounting 1 mount points...
Successfully remounted /data/users/strager/fbsource-dev
Started edenfs (pid 2792025)
Logs available at /data/users/strager/.eden-dev/logs/edenfs.log
```
These startup logs are also used by various tests (especially 'eden restart's tests).
Make the same thing happen when running 'eden start' with systemd integration, improving the user experience and making some tests work:
```
$ EDEN_EXPERIMENTAL_SYSTEMD=1 \
./buck-out/gen/eden/cli/eden.par start \
--daemon-binary "${PWD}/buck-out/gen/eden/fs/service/edenfs"
Starting edenfs (dev build), pid 2800760
Opening local RocksDB store...
Opened RocksDB store in 0.693 seconds.
Remounting 1 mount points...
Successfully remounted /data/users/strager/fbsource-dev
Started edenfs (pid 2800760)
```
Reviewed By: wez
Differential Revision: D13241979
fbshipit-source-id: de79b714e42b690fdab7c21d9add46bc2da35328
Summary:
Add the plumbing necessary to make 'eden start' start a systemd user service. This is only enabled if you opt in using EDEN_EXPERIMENTAL_SYSTEMD.
Currently, only fake_edenfs works. The real edenfs doesn't work yet because it needs root access to configure mount points.
'eden restart', 'eden stop', etc. are not affected by this diff (and are probably broken with EDEN_EXPERIMENTAL_SYSTEMD enabled).
Reviewed By: simpkins
Differential Revision: D10849390
fbshipit-source-id: c087a6498951ff100e5c80bd07ad869b2709e1b3
Summary:
When running edenfs in daemonize mode (i.e. when --foreground is not specified), the daemon process inherits stdin from the parent and never closes it. This has two consequences:
* The daemon process holds a reference to stdin even after the parent exits. This causes tests to hang if they wait for EPIPE on stdin after waiting for the parent process to exit. (I discovered this issue when adding tests for 'eden start' in D10434379.)
* edenfs could potentially read from the terminal after 'eden start' has returned. I think this behavior is surprising and could potentially cause problems.
Promptly close stdin after forking the daemon process, since nothing inside the daemon needs stdin.
Reviewed By: simpkins
Differential Revision: D10442346
fbshipit-source-id: f3d287e8b48e121807f845b73a1a550e63efae25
Summary:
getLogPath in eden/fs/service/main.cpp ensures that a non-empty log path is given to DaemonStartupLogger::daemonize. An empty log path is not possible. DaemonStartupLogger behaves differently with an empty log path, but that behavior has caused problems (see D10439299).
Make DaemonStartupLogger require a (non-empty) log path, simplifying its implementation.
This diff should not change behavior.
Reviewed By: chadaustin
Differential Revision: D10227597
fbshipit-source-id: 37931528add51ab3e6e1b941478000297cb8b693
Summary:
The daemonizeIfRequested is implemented in the main edenfs process as well as in fake_edenfs. Consolidate the almost-identical implementations.
This diff should not change behavior.
Reviewed By: chadaustin
Differential Revision: D10439300
fbshipit-source-id: 6253668896de0f8393b92f4aa5ee8a8a2fcbfb31
Summary:
StartupLogger handles two independent scenarios: edenfs in daemon mode, and edenfs in foreground mode. I need to add a third for systemd support: edenfs in foreground mode but with startup logs written to a file.
Refactor the existing StartupLogger into an abstract base class with two concrete derived classes: DaemonStartupLogger and ForegroundStartupLogger. This will make adding the systemd feature easy without confusing the logic for the existing scenarios.
Aside from dropping the setsid() call for ForegroundStartupLogger, this diff should not change behavior.
Reviewed By: simpkins
Differential Revision: D10228156
fbshipit-source-id: fbc2c771c6fbb675779ef05ca3b7395b70b67485
Summary:
D10370931 made all logs from StartupLogger use origStderr_ and never origStdout_. origStdout_ is thus unused. Delete origStdout_.
This diff should not change behavior.
Reviewed By: pkaush
Differential Revision: D10371294
fbshipit-source-id: 5dc1049192fea68a064a81143ea140c07452ecef
Summary:
Logging some messages to stdout and some messages to stderr has a few problems:
* stdout and stderr can get interleaved. For pipes, interleaving is avoidable for messages smaller than PIPE_BUF (512 bytes), but there's no guarantee that stdout and stderr are pipes or that the reader of the pipe reads PIPE_BUF bytes at a time.
* For the systemd integration I am developing, I need one file for stderr logs and another file for stdout logs. This is more complicated than having a single file for all logs.
* The distinction between stdout and stderr is unclear. No messages from StartupLogger are meant to be piped to another program.
Address these problems by only logging to stderr.
From a user's point of view, this diff should not change behavior.
Reviewed By: chadaustin
Differential Revision: D10370931
fbshipit-source-id: b063ed3a66cefc846d30ce1486759cbd3f3ea29e
Summary:
I want to split the StartupLogger class (see D10228156). The split will make logPath_ inaccessible from the success() function. I see two solutions:
* Make successImpl() (called by success()) write the entire message. This means each implementation of successImpl() needs to log the same "Started edenfs" message.
* Make success() write just the "Started edenfs" message, and have successImpl() write the "Logs available at" message (if possible). This means each implementation of successImpl() which has a log file needs to log the same "Logs available at" message, but in the short term there will be only one such implementation.
Implement the latter solution to minimize source code size.
Reviewed By: simpkins
Differential Revision: D10228164
fbshipit-source-id: aaa03e9d8c1d08c00a388a7fcaa76aa3f629decf
Summary:
This diff is first in the series to make Eden work on Windows. It includes:
1. HG backing store and Object store, which provides the capability to talk to mercurial and fetch the file and folder contents on Windows.
2. Subprocess and Pipe definition for Windows.
3. The Visual studio solution and projects files to compile Eden and scm datapack.
Few Important points:
1. Most of the changes to existing code is done under a macro EDEN_WIN so that it doesn't impact on other platform.
2. Sqlite is used for caching the fetched contents. We are not using Rocksdb on Windows.
3. The main function only calls some test code and exit after printing the output.
4. The initializeMononoke code is disabled for Windows because it needs Proxygen to talk HTTP. Will enable this once I get Proxygen and other dependencies working.
5. HgImporter pass Windows handles to hg_import_helper as command line args. The code to convert these handles into fds is in a separate diff.
Reviewed By: wez
Differential Revision: D8653992
fbshipit-source-id: 52a3c3750425fb92c2a7158c2c214a9372661e13
Summary: This update adds the name of the function which called the LOG() to the `LogMessage` object so that a custom formatter could use it to show method name with logs.
Reviewed By: simpkins
Differential Revision: D9071926
fbshipit-source-id: 9d5359d84cf2544371c6f1826f99d8b47a272dd1
Summary:
This adds a small helper class for printing startup status messages to the
user, and for signaling startup status over a pipe.
This will make it possible in a future diff for edenfs to daemonize, but still
communicate messages back to the parent process to report what it is doing
until it finishes the start-up steps.
Reviewed By: strager
Differential Revision: D8372250
fbshipit-source-id: 53a897944beeb1582a090a2b69afbc2b41408d52
