StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
14322036
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-01-14T16:02:47.597
FavoriteCount
0
LastActivityDate
2013-01-14T16:49:35.877
LastEditDate
2013-01-14T16:49:35.877
LastEditorUserId
174011
OwnerUserId
174011
ParentId
13679591
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I have a similar problem, but first, I'll give you tips to debug your problem: <ul> <li>Look at your process hierarchy to know if there are process that shouldn't be there. <code>ps faux</code></li> <li>If a process is left hanging on something, and you don't know what, you can <code>strace -p <PID></code> to look at the system call that is blocking the process</li> <li>If this is about a file descriptor (blocking on a read or write call), then you can look at the file descriptors for that process using <code>lsof -p <PID></code></li> <li>Now, if you want to look at what other processes are using this file descriptor, you can look at the number on the <code>NODE</code> column and run: <code>lsof | grep <NODE></code></li> </ul> The problem I had was that the standard output and standard error from the hook script were trapped by git in a pipe to forward them to the remote host (the host that did a git push). Also, my script restarted the postgresql daemon. As a consequence, postgresql inherited the standard output and standard error from git. That is, the pipe that forwards everything back to the remote hit host. One solution is to close stdout and stderr if you spawn services, by doing for example: <pre><code>service postgresql restart >&- 2>&- <&- </code></pre> But, you won't get any error message. The other and more generic solution I fould was to put the following code in my post-update hook: <pre><code># Creates a temp file t="$(tempfile)" || exit trap "rm -f -- '$t'" EXIT # Run the script # You need to run the script in background, and to redirect its standard and # error output to $t bash path/to/script.bash >"$t" 2>&1 </dev/null & # use tail -f to follow the output of the script, and --pid to exit when the # previous script exits ($! is the pid of the script). This might not be very # portable though tail -n 0 --pid $! -f "$t" # Clean up temp file # if a process is still attached to it, the inode won't be cleared until the # process close the file or dies. In our case, we don't care much. rm -f -- "$t" trap - EXIT </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODifference between SSH login and git push login (script execution context)
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USMildred
UserOwnerUserId
1. USMildred
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.