Jeremy Chadwick
2010-Sep-30 06:51 UTC
mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
Something interesting I've come across which happens on both RELENG_7
and RELENG_8 (indicating it's not a problem with the older tty code or
the newer pty/pts code), and it's reproducible on Linux (sort of...).
mysqld_safe appears to hold a pty/tty open even after the process has
been backgrounded. I can understand how/why this might occur, just not
in this particular case.
I had a colleague test the situation on his Linux machine. He was able
to confirm that:
1) "mysqld_safe > /dev/null 2>&1 &" never released the
tty
2) "nohup mysqld_safe > /dev/null 2>&1 &" did release
the tty
With regards to test #1, looking in /proc/{pid}/fd showed that STDIN was
being held open. I recommended he point STDIN to /dev/null as so:
"mysqld_safe < /dev/null > /dev/null 2>&1 &"
Which also solved the problem.
On FreeBSD it's a different story. Below, mysql-server was started as
root on pts/1. The open file descriptors all point to /dev/null, so I'm
not sure why the pty/tty is being held open.
icarus# ps -aux -U mysql
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mysql 10078 0.2 0.3 35100 11032 1 S 11:38PM 0:00.02 [mysqld]
mysql 9997 0.0 0.0 8228 1592 1 S 11:38PM 0:00.01 /bin/sh
/usr/local/bin/mysqld_safe --defaults-extra-file=/storage/mys
icarus# procstat -f 9997
PID COMM FD T V FLAGS REF OFFSET PRO NAME
9997 sh cwd v d -------- - - - /root
9997 sh root v d -------- - - - /
9997 sh 0 v c r------- 1 0 - /dev/null
9997 sh 1 v c -w------ 2 0 - /dev/null
9997 sh 2 v c -w------ 2 0 - /dev/null
icarus# procstat -f 10078
PID COMM FD T V FLAGS REF OFFSET PRO NAME
10078 mysqld cwd v d -------- - - - /storage/mysql
10078 mysqld root v d -------- - - - /
10078 mysqld 0 v c r------- 1 0 - /dev/null
10078 mysqld 1 v r rwa----- 1 32048 -
/storage/mysql/icarus.home.lan.err
10078 mysqld 2 v r rwa----- 1 32380 -
/storage/mysql/icarus.home.lan.err
At this point I log out of pts/1 and log back in to the machine (which
sticks me on pts/2 as a result of the problem). Looking again, we see:
icarus# ps -aux -U mysql
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mysql 9997 0.0 0.0 8228 1592 1- I 11:38PM 0:00.01 /bin/sh
/usr/local/bin/mysqld_safe --defaults-extra-file=/storage/mys
mysql 10078 0.0 0.3 35100 11032 1- I 11:38PM 0:00.02 [mysqld]
With absolutely no change in procstat output relevant to fds 0/1/2.
Yet pts/1 still appears held open by something:
icarus# ls -l /dev/pts
total 0
crw--w---- 1 jdc tty 0, 116 Sep 29 23:44 0
crw-rw-rw- 1 root wheel 0, 115 Sep 29 23:41 1
crw--w---- 1 jdc tty 0, 117 Sep 29 23:44 2
fstat also shows no indication of anything using pts/1:
icarus# fstat /dev/pts/1
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME
icarus# fstat | grep pts/1
icarus#
Ideas?
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Adam Vande More
2010-Sep-30 07:00 UTC
mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
On Thu, Sep 30, 2010 at 1:51 AM, Jeremy Chadwick <freebsd@jdc.parodius.com>wrote:> Something interesting I've come across which happens on both RELENG_7 > and RELENG_8 (indicating it's not a problem with the older tty code or > the newer pty/pts code), and it's reproducible on Linux (sort of...). > > mysqld_safe appears to hold a pty/tty open even after the process has > been backgrounded. I can understand how/why this might occur, just not > in this particular case. >Actually cam across this the other day: http://lists.freebsd.org/pipermail/freebsd-ports/2010-July/062417.html It appears you aren't the only one to notice the issue. -- Adam Vande More
Ed Schouten
2010-Sep-30 07:03 UTC
mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
Hi Jeremy, * Jeremy Chadwick <freebsd@jdc.parodius.com> wrote:> 1) "mysqld_safe > /dev/null 2>&1 &" never released the tty > 2) "nohup mysqld_safe > /dev/null 2>&1 &" did release the ttyWhat happens if you run the following command? daemon -cf mysqld_safe The point is that FreeBSD's pts(4) driver only deallocates TTYs when it's really sure nothing uses it anymore. Even if there is not a single file descriptor referring to the slave device, it has to wait until there exist no processes which have the TTY as its controlling TTY. The `pstat -t' command is quite useful to figure out whether there is still a session associated with the TTY. See the following thread: http://lists.freebsd.org/pipermail/freebsd-ports/2010-July/062417.html -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100930/a83e9e65/attachment.pgp
Jilles Tjoelker
2010-Oct-01 12:55 UTC
mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
On Thu, Sep 30, 2010 at 09:03:33AM +0200, Ed Schouten wrote:> * Jeremy Chadwick <freebsd@jdc.parodius.com> wrote: > > 1) "mysqld_safe > /dev/null 2>&1 &" never released the tty > > 2) "nohup mysqld_safe > /dev/null 2>&1 &" did release the tty> What happens if you run the following command?> daemon -cf mysqld_safe> The point is that FreeBSD's pts(4) driver only deallocates TTYs when > it's really sure nothing uses it anymore. Even if there is not a single > file descriptor referring to the slave device, it has to wait until > there exist no processes which have the TTY as its controlling TTY.In fact, POSIX allows dissociating the controlling terminal from the session when all file descriptors for it (in any session) have been closed. See SUSv4 XBD 11.1.3 The Controlling Terminal. Once the terminal has been dissociated, it is no longer in use at all and can, in case of a pty, be cleaned up. Implementing this may be an interesting idea. Of course, this will cause opening /dev/tty to fail in some cases where it previously succeeded, but it seems uncommon. Somewhat unrelated, I think that starting daemons with daemon(8), </dev/null >/dev/null 2>&1 or similar is inferior to implementing daemonizing in the program itself. Think of the poor soul who needs to install and start N daemons full of bugs and configuration errors: it is better if such errors show up on the console instead of being hidden away in a log file. -- Jilles Tjoelker