cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rust (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13085) Cassandra fails to start because WindowsFailedSnapshotTracker can not write to CASSANDRA_HOME
Date Fri, 01 Sep 2017 17:06:00 GMT


Jason Rust commented on CASSANDRA-13085:

We've also hit this issue when trying to deploy C* on windows.  If a new directory is chosen
it might make sense to also use that as the default in the HeapUtils class, the only other
class that references and tries to write to the CASSANDRA_HOME folder.

A less-invasive workaround I've found is to set CASSANDRA_HOME to the data directory as the
very last line of cassandra-env.ps1.  This allows the libraries to be sourced from the real
CASSANDRA_HOME, but then overwrites the variable before C* actually launches.

> Cassandra fails to start because WindowsFailedSnapshotTracker can not write to CASSANDRA_HOME
> ---------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-13085
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths, Packaging
>         Environment: might be windows only considering the classname
>            Reporter: Pieter-Jan Pintens
>              Labels: windows
> We are currently trying to package Cassandra with our application.
> In windows our server does not want to start because it want to write to CASSANDRA_HOME\.toDelete,
since we install to 'C:\program files\...' this is not possible when started under a non privileged
user. We were hoping that setting pointers for the data and log dir to a writable location
(somewhere under user home) would be enough to start cassandra but this component wants to
write to a path that we cannot modify.
> For us there are a couple of solutions:
> 1) the location can be specified using a system property like data and log dirs
> 2) this file is written to the data location
> Our current work arround would be to patch this class file but that is hard to maintain.
> {noformat}
> Exception (java.lang.RuntimeException) encountered during startup: Failed to cre
> ate failed snapshot tracking file [.toDelete]. Aborting
> java.lang.RuntimeException: Failed to create failed snapshot tracking file [.toDelete].
>         at org.apache.cassandra.db.WindowsFailedSnapshotTracker.deleteOldSnapshots(
>         at org.apache.cassandra.service.CassandraDaemon.setup(
>         at org.apache.cassandra.service.CassandraDaemon.activate(
>         at org.apache.cassandra.service.CassandraDaemon.main(
>         at Source)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
> {noformat}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message