Bug 843832 - RFE: introduce db.target
RFE: introduce db.target
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-07-27 09:42 EDT by Jóhann B. Guðmundsson
Modified: 2013-01-16 09:49 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-15 15:22:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
database-daemon.target (355 bytes, application/octet-stream)
2012-08-01 11:07 EDT, Jóhann B. Guðmundsson
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2012-07-27 09:42:22 EDT
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):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Michal Schmidt 2012-07-31 10:05:25 EDT
If I understand correctly, the purpose of db.target is to simplify cases like this?:

  After=mysql.service postgresql.service

Does this pattern occur often in unit files?
Comment 2 Jóhann B. Guðmundsson 2012-07-31 13:39:42 EDT
(In reply to comment #1)
> Jóhann,
> If I understand correctly, the purpose of db.target is to simplify cases
> like this?:
>   [Unit]
>   ...
>   After=mysql.service postgresql.service
>   ...

Amongst other things yes  

> Does this pattern occur often in unit files?

Comment 3 Jóhann B. Guðmundsson 2012-08-01 11:07:59 EDT
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?
Comment 4 Bill Nottingham 2012-08-01 13:12:22 EDT
From the code:

                /* common extensions */
                "mail-transfer-agent",  SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
                "x-display-manager",    SPECIAL_DISPLAY_MANAGER_SERVICE,
                "null",                 NULL,

#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || defined(TARGET_ANGSTROM)
                "mail-transport-agent", SPECIAL_MAIL_TRANSFER_AGENT_TARGET,

                "MTA",                  SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
                "smtpdaemon",           SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
                "httpd",                SPECIAL_HTTP_DAEMON_TARGET,

                "smtp",                 SPECIAL_MAIL_TRANSFER_AGENT_TARGET,

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.)
Comment 5 Jóhann B. Guðmundsson 2012-08-01 14:45:33 EDT
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. 


Comment 6 Bill Nottingham 2012-08-01 15:02:24 EDT
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?
Comment 7 Jóhann B. Guðmundsson 2012-08-01 15:48:05 EDT
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?
Comment 8 Kay Sievers 2012-08-02 08:27:52 EDT
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
than good.
Comment 9 Lennart Poettering 2012-10-30 17:19:08 EDT
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?
Comment 10 Kay Sievers 2013-01-15 15:22:34 EST
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.
Comment 11 Jóhann B. Guðmundsson 2013-01-15 15:53:37 EST
So what's the difference between httpd.target and db.target? You have multiple web servers we have multiple databases?
Comment 12 Lennart Poettering 2013-01-15 16:29:17 EST
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....
Comment 13 Jóhann B. Guðmundsson 2013-01-16 04:24:23 EST
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...
Comment 14 Kay Sievers 2013-01-16 09:49:24 EST
(In reply to comment #13)
> If we are going to base .targets upon protocols then we lack a whole lot of
> them...

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.

Note You need to log in before you can comment on or make changes to this bug.