Red Hat Bugzilla – Bug 843832
RFE: introduce db.target
Last modified: 2013-01-16 09:49:24 EST
Description of problem:
We need to introduce db.target so we can fix ordering properly in my clean up process as in which we will tie all our database service/daemons to the db.target and I will fix all orderings of service to be started after that instead individual database services
Version-Release number of selected component (if applicable):
Steps to Reproduce:
If I understand correctly, the purpose of db.target is to simplify cases like this?:
Does this pattern occur often in unit files?
(In reply to comment #1)
> If I understand correctly, the purpose of db.target is to simplify cases
> like this?:
> After=mysql.service postgresql.service
Amongst other things yes
> Does this pattern occur often in unit files?
Created attachment 601764 [details]
following the poorly named httpd-daemon convention
I guess something like this should be necessary man pages update.
A target for pulling in an database server(s) if there is any.
Can you guys point me to where you guys found the LSB header referring to the $httpd facility in the Linux Standard Base Core Specification.
I must be blind or something since I cant find it neither in 3.x nor 4.x.
The only facility names that I can find are
Should not systemd be pushed into LSB as well?
From the code:
/* common extensions */
#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || defined(TARGET_ANGSTROM)
I suspect some of these will go away as more things migrate away from them, especially given that they weren't consistently used in Fedora anyway. (I can't find in a brief check of F-14 where httpd was used at all.)
Well they will be once I have run the cleanup process
Anywho from the looks of this we should be introducing mta-daemon.target along with the missing named-daemon.target as well.
personally I would prefer if we dropped the "daemon" part from those target names and probably httpd-daemon.target should be renamed to web.target and named-daemon.target to dns.target since httpd might be referring to apache and named to bind
So the global service targets would be.
How many of these are actually needed and would not be covered by socket activation or similar items?
Similarly, given the doucmented existence and support in systemd for mail-transfer-agent, nss-lookup, and http-daemon, is there a great need to rename them now?
Many with us more with services/daemons in Debian.
With regards to naming of the targets for the future then yes I think it's necessary and we should just symbolic link to the old names if necessary.
Dont confuse my request with the current lsb I'm doing this because I see the need to do this with units based on my experience and the way forward rather then keeping some backwards compatibility with lsb.
I would like us to introduce all the previous mentioned target preferably in that naming schema which arguably is for the same reason that they exist in the lsb in the first place.
I would be still making the same request if lsb never had come to be...
By the way had you guys planned pushing for change in the System Initialization part of LSB?
What would *the* db be, or *the* http server, or ...
I don't think that really fits, we should only do stuff that is really
*global*, which is part of the core system bring-up, and which usually
is an obvious task of bootup, and also in most cases a single instance
I'm not sure about renaming these things. We should be very careful and not
pretend to provide global checkpoints for the global system state. It gets us
in to the world of unsolvable stuff like network.target, which can by its
very definition not exist in today's reality.
We have most of the legacy targets only to provide some matching with the
far-too-simple-and -aive SYSV idea of a system. Not saying they are all wrong,
but the majority of the SYSV targets is pure wishful thinking how systems work
in reality, some of them are a fundamentally broken concept as a hook to
use and make any assumptions.
The point I'm trying to make is that these global targets are usually just
checkpoints for broken things that should just be fixed instead, and not
this stuff extended further the point of required compatibility with SYSV
legacy, which ideally just dies over time.
We need to be very very careful here, it might in the end do more damage
Before we introduce any new targets like this, I'd like to see concrete usecases. Hence:
Which services would order themselves before db.target? And which ones after? And why would they?
We should not add arbitrary target names, which have no clear meaning or use cases for the global system.
Services need their own explicit dependencies, there is not *one database* per system, and we must never order against multiple independent databases.
So what's the difference between httpd.target and db.target? You have multiple web servers we have multiple databases?
Johann, well, I think we should probably get rid of httpd.target too (we kinda inherited tht from Debian, since Debian had that as LSB facility). However, there is one fundamental difference: HTTP is a generic protocol, understood universally by web servers and clients alike. This is different from databases, where no standardized protocol exists, and a pg client hence can only talk to a pg server, and a mysql client to a mysql server, but not a pg client to a mysql service.
Hope that makes some sense....
I look at this from a practical unit dependency and I'm perfectly aware of the difference between postgresql and mysql and other database but these run on different ports and ordering units After= each $DB out there and trying to maintain is impractical from my point view since it's much simpler to create database.target order all units After= that, and have each unit for databases themselves to have
If we are going to base .targets upon protocols then we lack a whole lot of them...
(In reply to comment #13)
> If we are going to base .targets upon protocols then we lack a whole lot of
There are none left, httpd.target was removed quite some time ago.
All the other non-LSB facilities are now removed from systemd now too. We
should not invent artificial barriers for the global system state, be them generic protocols or generic service class dependencies.