Bug 843832

Jóhann,
If I understand correctly, the purpose of db.target is to simplify cases like this?:

  [Unit]
  ...
  After=mysql.service postgresql.service
  ...

Does this pattern occur often in unit files?

(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?

Yes

Created attachment 601764 [details]
database-daemon.target

following the poorly named httpd-daemon convention       

I guess something like this should be necessary man pages update.

database-daemon.target
           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

$local_fs	 	
$network	 	
$named	 	
$portmap	 	
$remote_fs	 	
$syslog	 	
$time

Should not systemd be pushed into LSB as well?

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,
#endif

#ifdef TARGET_FEDORA
                "MTA",                  SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
                "smtpdaemon",           SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
                "httpd",                SPECIAL_HTTP_DAEMON_TARGET,
#endif

#ifdef TARGET_SUSE
                "smtp",                 SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
#endif
...

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. 

database.target
dns.target
mta.target
web.target

thoughts?

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
implementation.

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.

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 
[Install]
WantedBy=database.target

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
> 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.