Jump to content


Lost my Depot - Help!

linux

  • Please log in to reply
7 replies to this topic

#1 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 01 April 2020 - 10:28 AM

Hey,

Just trying to get a basic perforce setup and working. I installed perforce on a Linux remote server and all was working fine.

When I was doing some work in p4admin (making new users, setting new groups), something hiccuped and the client kept asking me for my superuser password over and over again without doing anything. I tried to restart the p4admin client but it wasn't working or letting me log in. So I just went and restarted the linux server and used the 'p4d' command to start up the perforce server.

Logging back in via the p4admin client, all of my users and my accounts are gone... I had to sign in from scratch, as if it was a new install of perforce. My Depot is missing in the depot view (but the disk space usage is reporting that the files are still there)

I checked the terminal command logging in (p4 set P4PORT=IP:PORT), and typed in 'p4 info', the 'server root' field is empty and it says 'Client unknown'

Help!!! What do I do?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1172 posts

Posted 01 April 2020 - 01:57 PM

When you restarted p4d, you didn't specify the server root (which is where the database lives).  Just kill that p4d process and restart it, but this time do it in the right directory, or specify the root path with "-r ~/p4root" or wherever it lives.

#3 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 01 April 2020 - 04:25 PM

View PostSambwise, on 01 April 2020 - 01:57 PM, said:

When you restarted p4d, you didn't specify the server root (which is where the database lives).  Just kill that p4d process and restart it, but this time do it in the right directory, or specify the root path with "-r ~/p4root" or wherever it lives.

Thanks, ok will try. I don't remember specifying a root path when I first started it though, how do I 'kill' the p4d process on linux and how do I specify the root path?

*Edit how do I know where the database is?

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1172 posts

Posted 01 April 2020 - 10:59 PM

View Postsubressor, on 01 April 2020 - 04:25 PM, said:

I don't remember specifying a root path when I first started it though

It defaults to the current working directory, so it'd be whatever directory you were in when you started p4d the first time.

Quote

how do I 'kill' the p4d process on linux

The "kill" command (use the "ps" command to find the PID to use with "kill"), or use "p4 admin stop" from the client (which will tell p4d to terminate itself).

Quote

and how do I specify the root path?

The "-r" flag to p4d.  For example:

p4d -r /some/root/path

Or: cd to the correct path before starting p4d.  Or: set P4ROOT in your environment to point to that path.

Quote

*Edit how do I know where the database is?

The database is in the P4ROOT path.  It consists of a bunch of files whose names start with db.  Note that because you started an instance of p4d in a new root path, you now have TWO sets of database files; look at the file sizes and dates to know which one is the "empty" set you just started and which actually has your content in it from before.

#5 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 02 April 2020 - 09:26 AM

Ahh sugar, you're a lifesaver dude, thanks a ton! Let me give it a go and I'll report back :-)

#6 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 03 April 2020 - 10:15 AM

Hey Sambwse,

You've been super helpful on more than one of my posts, thanks very much dude!

Unfortunately, I just couldn't get it to work...
  • I did some linux navigation and found that the depot name was at the root of the drive ( /depot/...). But I found 3 'collections' of db.* files...
  • It looked like the depot was owned by 'root' user, not by the 'perforce' user I had set up to own/run the p4d instance. It took a lot of closing/opening putty because every time you start the server, it says 'perforce server starting' and locks the terminal so that you can't do anything else...
  • Finally, after getting the correct instance running in the right place by the root user, I then tried signing in from my client but it kept asking for my password endlessly (which was the initial reason why I restarted the server!).
  • In a saddened slump, I threw in the towel and went to cuddle my cat for the next few hours before going to bed.

The next day I just installed p4d on a new Windows server VM. It took 1/4 of the time and everything just worked great. I was even able to download an older cloud-saved copy of all of my files and load them onto the server locally by installing P4V.

Now I'm trying to copy the files I already have on my computer to my newly mapped work-space and ask perforce to recognise/link them to the depot instead of downloading the whole thing again... I feel like it's going to be a long journey learning this software :/

#7 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1172 posts

Posted 03 April 2020 - 02:17 PM

View Postsubressor, on 03 April 2020 - 10:15 AM, said:

I did some linux navigation and found that the depot name was at the root of the drive ( /depot/...). But I found 3 'collections' of db.* files...

That suggests that maybe you started up the server with a P4ROOT of "/" (the literal system root), which is not great for obvious reasons.  

Quote

It looked like the depot was owned by 'root' user, not by the 'perforce' user I had set up to own/run the p4d instance.

That makes sense, since only root would be allowed to write files directly into the system root directory.  You must have logged in as root before running "p4d", and done so in the system root directory.  Instead you'd want to log in as the "perforce" user before running p4d (and probably also set p4d up to run as a cronjob under the "perforce" user so you wouldn't have to start it manually).

Quote

It took a lot of closing/opening putty because every time you start the server, it says 'perforce server starting' and locks the terminal so that you can't do anything else...

Opening multiple terminals is fine.  You can also tell p4d to run in the background by using the "-d" (for "daemon") flag, or by using the shell's "&" operator which tells it to fork the process (this works for any command where you want it to keep doing its thing while you get your terminal back).


Quote

Finally, after getting the correct instance running in the right place by the root user, I then tried signing in from my client but it kept asking for my password endlessly (which
was the initial reason why I restarted the server!).

To be honest I'd just recommend against using P4Admin, because that sounds like buggy client behavior, and IMO server administration is adequately simple from the command line that it's not worth wrestling with a GUI.

Quote

Now I'm trying to copy the files I already have on my computer to my newly mapped work-space and ask perforce to recognise/link them to the depot instead of downloading the whole thing again...

If you've set up a new server and want to add the contents of your old workspace to it, you can do that without copying any files around.  Just create a workspace for the new server that's in the same location as the one you used for the old server (note that you wouldn't want to do this for two different servers you're using at the same time, but since this is your one and only server it's fine to just port your old client environment over to it).  Then "add" all the files and "submit" them, easy peasy.

cd C:\my_workspace\folder
p4 client
p4 add ...
p4 submit -d "Ta da!"


#8 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 07 April 2020 - 12:46 PM

Thanks for the super detailed answer! I'll give it another go on my Windows machine with some other files I need to change.

I'm not sure if it was a problem Linux was interfering with





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users