[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

Both mysql-server-5.5 and mysql-server-5.6 packages (e.g. under Trusty Thar) provide a sysvinit script and an upstart job for mysql. The problem here is that the maintainer has a very strange approach: 1. The sysvinit script links are symply removed in the postinstall script using update-rc.d

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

** Changed in: upstart (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

** Tags removed: scripts verification-done-trusty verification-needed ** Tags added: trusty verification-done -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1273462 Title: Users can

Re: [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

On 3 December 2015 at 17:41, Mark Stosberg wrote: > In Bug #1521771, I spent some time tracking down different behavior > between the mysql-5.5 "init" and "upstart" scripts. They differ on how > many seconds are waited between the SIGTERM and SIGKILL signals are > sent.

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

Marking as verified on Trusty since I was able to do more testing. ** Tags added: verification-done-trusty -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1273462 Title: Users can

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

In Bug #1521771, I spent some time tracking down different behavior between the mysql-5.5 "init" and "upstart" scripts. They differ on how many seconds are waited between the SIGTERM and SIGKILL signals are sent. Different values can mean the difference between a slower clean shutdown and a

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

** Changed in: lsb (Ubuntu) Importance: Undecided => High ** Changed in: lsb (Ubuntu Utopic) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1273462

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

** No longer affects: mysql-5.5 (Ubuntu) ** No longer affects: mysql-5.5 (Ubuntu Trusty) ** No longer affects: mysql-5.5 (Ubuntu Utopic) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report.

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

** Branch linked: lp:ubuntu/trusty-proposed/lsb -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause problems if an

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

I couldn't find any regression in my testing but since it wasn't that extensive, I'm not marking it a verified just yet. I really like the behavior improvement. Now, a regular user has a convenient way to check service statuses: /etc/init.d/acpid status Instead of the obtuse old way: env

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

Hello Eric, or anyone else affected, Accepted lsb into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu6.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

I sponsored this a while ago, unsubscribing sponsors. This is in the hands of the SRU team now. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

@Martin Note that this is bug a regression - previously, before the (I presume) dh_installinit change, /etc/init.d/foo was a symlink to /lib/init /upstart-job so a user running /etc/init.d/foo by hand was redirected to upstart anyway. So while I appreciate that a user might now be getting desired

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

I still disagree that it's "undefined behaviour" -- if we have used the actual init.d script so far to start e. g. mysql under upstart, then this does not sound either racy nor undefined; it surely isn't what we *intended* to do, though? My concern is, this fix will change behaviour for *all*

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

> Thus in trusty you don't have the option to use dependency-based > sysvinit scripts, you *have* to have rc?.d symlinks; and they are > being used through upstart too via /etc/init/rc.conf. In that case, any /etc/rc?.d symlink that shadows an upstart job is still going to be doing the wrong

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

> No /etc/rc?.d/ links Of course, but I thought the point here was that one could/would call /etc/init.d/mysql directly when doing manual admin operations. The first part of the patch, which disables an init.d script when called through /etc/rc?.d/ is correct; if this happens (upstart job with

Re: [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

On Wed, Sep 02, 2015 at 03:26:49PM -, Martin Pitt wrote: > I still disagree that it's "undefined behaviour" -- if we have used the > actual init.d script so far to start e. g. mysql under upstart, That is *not* what we're doing. Installing the mysql-server-5.5 package on trusty gives you: $

Re: [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

Steve Langasek [2015-09-01 21:38 -]: > The *only* thing that's made a no-op is the invocation of the init > script *by the rc?.d symlink*. This is something that should never > happen anyway; our dependency-based boot is already supposed to bypass > invoking this script in favor of the

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

> I think this should be the responsibility of existing packages to make they are doing the correct thing. That is not sufficient for an SRU. Your SRU needs to be compatible with the existing packages in the archive /as they are/, not as you declare they should be. However, per my previous

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

I think the change description within the patch is wrong (or at least, misleading/incomplete). What this patch actually does is: - for anything that calls /etc/init.d/foo, if /etc/init/foo.conf exists, make the call a passthrough to upstart instead of calling the init script. - for anything

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

upstart init-functions.d hook has ended up being shipped by lsb, since circular dependencies onto upstart from sysv are a bad idea. Hence re- assigning SRU to lsb. ** Changed in: upstart (Ubuntu Trusty) Status: Triaged = Won't Fix ** Also affects: lsb (Ubuntu) Importance: Undecided

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

This bug was fixed in the package upstart - 1.12.1-0ubuntu6 --- upstart (1.12.1-0ubuntu6) utopic; urgency=medium * Map force-reload to restart command in init-functions hook. * Use variable expansion, instead of basename as that is shipped in /usr. * Resolve test-failure,

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

** Also affects: upstart (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: mysql-5.5 (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: upstart (Ubuntu Utopic) Importance: Critical Assignee: Dimitri John Ledkov (xnox) Status:

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

lsb - upstart, because upstart will just provide lsb integration snippet ** Changed in: lsb (Ubuntu) Importance: Undecided = Critical ** Changed in: lsb (Ubuntu) Assignee: (unassigned) = Dimitri John Ledkov (xnox) ** Package changed: lsb (Ubuntu) = upstart (Ubuntu) -- You received