Re: 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 free...@jdc.parodius.com wrote: 1) mysqld_safe /dev/null 21 never released the tty 2) nohup mysqld_safe /dev/null 21 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 21 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
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 21 never released the tty
2) nohup mysqld_safe /dev/null 21 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 21
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
USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mysql 10078 0.2 0.3 35100 11032 1 S11:38PM 0:00.02 [mysqld]
mysql 9997 0.0 0.0 8228 1592 1 S11: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 FLAGSREF OFFSET PRO NAME
9997 shcwd 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 FLAGSREF OFFSET PRO NAME
10078 mysqldcwd 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
USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mysql 9997 0.0 0.0 8228 1592 1- I11: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- I11: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 wheel0, 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 j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 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 free...@jdc.parodius.comwrote: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
Hi Jeremy, * Jeremy Chadwick free...@jdc.parodius.com wrote: 1) mysqld_safe /dev/null 21 never released the tty 2) nohup mysqld_safe /dev/null 21 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. 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 e...@80386.nl WWW: http://80386.nl/ pgpq5AlaJIXSZ.pgp Description: PGP signature
Re: 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: Hi Jeremy, * Jeremy Chadwick free...@jdc.parodius.com wrote: 1) mysqld_safe /dev/null 21 never released the tty 2) nohup mysqld_safe /dev/null 21 did release the tty What happens if you run the following command? daemon -cf mysqld_safe Let's try it and find out. This is all being done from pts/2. icarus# ps -auxwww -U mysql | grep mysqld_safe mysql9997 0.0 0.0 8228 1592 1- I11:38PM 0:00.01 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/storage/mysql/my.cnf --user=mysql --datadir=/storage/mysql --pid-file=/storage/mysql/icarus.home.lan.pid --skip-innodb icarus# /usr/local/etc/rc.d/mysql-server stop Stopping mysql. Waiting for PIDS: 10078. icarus# daemon -c -f -u mysql /usr/local/bin/mysqld_safe --defaults-extra-file=/storage/mysql/my.cnf --user=mysql --datadir=/storage/mysql --pid-file=/storage/mysql/icarus.home.lan.pid --skip-innodb icarus# ps -auxwww -U mysql USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND mysql 11036 0.0 0.0 8228 1600 ?? Is 12:21AM 0:00.01 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/storage/mysql/my.cnf --user=mysql --datadir=/storage/mysql --pid-file=/storage/mysql/icarus.home.lan.pid --skip-innodb mysql 6 0.0 0.3 35100 11032 ?? I12:21AM 0:00.02 [mysqld] icarus# exit $ exit [another window, different tty] icarus# pstat -t | grep pts/2 icarus# Summary: looks good to me. 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. Ah I see. Well that would explain the difference between Linux and FreeBSD then -- it sounds like Linux has a one-off with regards to fds that point to /dev/null. 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 Ahhh, two people pointing me to the same thread, sweet. :-) I wasn't subscribed to -ports back in July, else I'd almost certainly have said something then. It's exactly as you stated in that thread -- the tty is in G state (waiting to be freed/process to exist). Please note the below output was obtained *before* attempting the daemon -cf stuff you recommended. icarus# pstat -t | grep pts/1 pts/1 0000 000 0 9372 0 G Until rc(8) can be updated to support daemon(8) natively, the ~76 ports which Do The Wrong Thing(tm) should get updated to do it this way. Ones like mysqlXX-server should be placed high on the priority list given their popularity/importance. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
On Thu, Sep 30, 2010 at 09:30:25AM +0200, Alex Dupre wrote:
Jeremy Chadwick ha scritto:
Until rc(8) can be updated to support daemon(8) natively,
This would be the Right Thing IMHO.
the ~76 ports
which Do The Wrong Thing(tm) should get updated to do it this way. Ones
like mysqlXX-server should be placed high on the priority list given
their popularity/importance.
If you have an already tested patch for the mysql rc script, I'll commit
it asap.
Just finished it for databases/mysql51-server. Tested on RELENG_8 with
the below variables in use, and also tested with mysql_limits=yes.
mysql_enable=yes
mysql_dbdir=/storage/mysql
mysql_args=--skip-innodb
Should work fine on RELENG_7 since it has /usr/sbin/daemon too.
Tested using stop, start, and restart. I can test a reboot if you'd
like, just let me know. Validation:
icarus# /usr/local/etc/rc.d/mysql-server stop
Stopping mysql.
Waiting for PIDS: 12015.
icarus# /usr/local/etc/rc.d/mysql-server start
Starting mysql.
icarus# ps -auxwww -U mysql
USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mysql 12271 0.0 0.0 8228 1600 ?? Is 12:53AM 0:00.01 /bin/sh
/usr/local/bin/mysqld_safe --defaults-extra-file=/storage/mysql/my.cnf
--user=mysql --datadir=/storage/mysql
--pid-file=/storage/mysql/icarus.home.lan.pid --skip-innodb
mysql 12352 0.0 0.3 35100 11032 ?? I12:53AM 0:00.02 [mysqld]
I'll also take this opportunity to point this out, since I'm certain
someone will mention it: daemon's -u argument would be ideal except that
it breaks when using rc.subr's xxx_user variable (which uses su(1)
to change credentials/spawn $command). With both in use, daemon then
fails on setusercontext(), which in turn fails because of initgroups()
returning EPERM -- and this does make sense. So let's not use daemon -u
in rc.subr for the time being.
The diff is pretty obvious/simple (2 line change), so the other
databases/mysqlXX-server ports can be upgraded in the same manner.
--- files/mysql-server.sh.in.orig 2010-03-27 03:24:53.0 -0700
+++ files/mysql-server.sh.in2010-09-30 00:45:38.0 -0700
@@ -35,8 +35,8 @@
mysql_user=mysql
mysql_limits_args=-e -U ${mysql_user}
pidfile=${mysql_dbdir}/`/bin/hostname`.pid
-command=%%PREFIX%%/bin/mysqld_safe
-command_args=--defaults-extra-file=${mysql_dbdir}/my.cnf --user=${mysql_user}
--datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args} /dev/null 21
+command=/usr/sbin/daemon
+command_args=-c -f /usr/local/bin/mysqld_safe
--defaults-extra-file=${mysql_dbdir}/my.cnf --user=${mysql_user}
--datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args}
procname=%%PREFIX%%/libexec/mysqld
start_precmd=${name}_prestart
start_postcmd=${name}_poststart
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
Jeremy Chadwick ha scritto: Until rc(8) can be updated to support daemon(8) natively, This would be the Right Thing IMHO. the ~76 ports which Do The Wrong Thing(tm) should get updated to do it this way. Ones like mysqlXX-server should be placed high on the priority list given their popularity/importance. If you have an already tested patch for the mysql rc script, I'll commit it asap. -- Alex Dupre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
On Thu, Sep 30, 2010 at 08:53:07AM -0400, Paul Mather wrote:
On Sep 30, 2010, at 3:56 AM, Jeremy Chadwick wrote:
The diff is pretty obvious/simple (2 line change), so the other
databases/mysqlXX-server ports can be upgraded in the same manner.
--- files/mysql-server.sh.in.orig 2010-03-27 03:24:53.0 -0700
+++ files/mysql-server.sh.in2010-09-30 00:45:38.0 -0700
@@ -35,8 +35,8 @@
mysql_user=mysql
mysql_limits_args=-e -U ${mysql_user}
pidfile=${mysql_dbdir}/`/bin/hostname`.pid
-command=%%PREFIX%%/bin/mysqld_safe
-command_args=--defaults-extra-file=${mysql_dbdir}/my.cnf
--user=${mysql_user} --datadir=${mysql_dbdir} --pid-file=${pidfile}
${mysql_args} /dev/null 21
+command=/usr/sbin/daemon
+command_args=-c -f /usr/local/bin/mysqld_safe
--defaults-extra-file=${mysql_dbdir}/my.cnf --user=${mysql_user}
--datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args}
Shouldn't this be -c -f %%PREFIX%%/bin/mysqld_safe ... rather than
hard-coding /usr/local?
Yes.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
On Sep 30, 2010, at 3:56 AM, Jeremy Chadwick wrote:
The diff is pretty obvious/simple (2 line change), so the other
databases/mysqlXX-server ports can be upgraded in the same manner.
--- files/mysql-server.sh.in.orig 2010-03-27 03:24:53.0 -0700
+++ files/mysql-server.sh.in 2010-09-30 00:45:38.0 -0700
@@ -35,8 +35,8 @@
mysql_user=mysql
mysql_limits_args=-e -U ${mysql_user}
pidfile=${mysql_dbdir}/`/bin/hostname`.pid
-command=%%PREFIX%%/bin/mysqld_safe
-command_args=--defaults-extra-file=${mysql_dbdir}/my.cnf
--user=${mysql_user} --datadir=${mysql_dbdir} --pid-file=${pidfile}
${mysql_args} /dev/null 21
+command=/usr/sbin/daemon
+command_args=-c -f /usr/local/bin/mysqld_safe
--defaults-extra-file=${mysql_dbdir}/my.cnf --user=${mysql_user}
--datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args}
Shouldn't this be -c -f %%PREFIX%%/bin/mysqld_safe ... rather than
hard-coding /usr/local?
procname=%%PREFIX%%/libexec/mysqld
start_precmd=${name}_prestart
start_postcmd=${name}_poststart
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Cheers,
Paul.___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
