Opened 12 years ago

Last modified 7 years ago

#4329 assigned Bug

transmission-daemon resets config path after SIGHUP

Reported by: stillinbeta Owned by: mike.dld
Priority: Normal Milestone: None Set
Component: Daemon Version: 2.31
Severity: Minor Keywords: sighup config


I'll admit I haven't tried out a nighly build. I'm running transmission from my router, and in absence of a MIPS build readily available and not wanting to install a toolchain for a single bug, I can't really accomplish this. I have taken a cursory look around the source, and it looks to my eye as if nothing relevant has changed since release.

Steps to reproduce are simple: Provide an alternate config dir with -g on the command line, observe the settings, and send a SIGHUP to the daemon. The daemon with disregard the command line argument and use config files from the default directory location, in my case .config/transmission/ was created in the process. My C is pretty weak, so I'm afraid I can't submit a patch, but I suspect it has something to do with tr_sessionGetConfigDir in libtransmission/platform.c

Change History (4)

comment:1 Changed 11 years ago by x190

stillinbeta, can't you stop the daemon first, then do the -g thing plus start the daemon all in one command? SIGHUP probably, as you say, just makes it reload the defaults.

comment:2 Changed 11 years ago by gvdl

  • Owner set to stillinbeta

I have traced the code. The code path is correct, once the daemon is up and saves the given config directory in the session at sessionInit time. Then this configDir is used later when a SIGHUP is received. So there is no apparent problem in the average save. I also checked that setConfigDir is only called in one place and I couldn't find any other areas where session->configDir is being set so the code seems to be clean.

Also there is a race condition with the signal handling during initialisation of the daemon, but I'll raise another bug for that.

There is a magic bit of code that says, if the configDir is NULL then return the default directory. But this would be a different bug, some part of the code would be scribbling over the session structure and that would be bad!

So stillinbeta Can you reproduce the bug with a long running (>10min) daemon? If so we may have a buffer overrun and I'd like to investigate that ASAP

Last edited 11 years ago by gvdl (previous) (diff)

comment:3 Changed 11 years ago by gvdl

While we are waiting I found a brief race during initialisation for which a patch has been submitted #4895.

comment:4 Changed 7 years ago by mike.dld

  • Owner changed from stillinbeta to mike.dld
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.