search

dCache / dcache

dCache - a system for storing and retrieving huge amounts of data, distributed among a large number of heterogenous server nodes, under a single virtual filesystem tree with a variety of standard access methods
https://dcache.org
292 stars 136 forks source link

systemd: "dcache start/stop" confuses systemd #3705

Closed calestyo closed 1 year ago

calestyo commented 7 years ago

Hey.

Just noted, when doing dcache stop or dcache start then systemd get's a bit confused, namely while the former two are usually considered to "start/stop all dcache on the system" (which people will think corresponds to dcache.service), it in fact only starts/stop each single domain (and on systemd each single instance unit) - the "global" service doesn't get started or stopped.

Thus when I started dCache e.g. via systemctl start dcache.service, but stop it via dcache stop systemd will not notice that dcache.service is no longer active.

This is not a big deal for now, but if people would start to use e.g. dcache.service (and it's state in their own units... e.g. as a dependency for a systemd controlled pnfs mount)... or in querying whether dcache runs... it could become one.

TBH, I think workarounds like checking in domainStart() and domainStop() are just hacks and would sooner or later cause problems. The main problem here is rather that we interfere again with what's not our business in a systemd world (starting/stopping services) (<--- and this shouldn't be read as a complaint... :-) .. it's just that the situation changes with systemd).

IMO, the proper solution is to deprecate/remove all dcache stop/start and similar things which are going to be obsolete sooner or later. But as with other such changes (dcache.user, dcache.log.dir, etc.) that's some bigger changes which you guys should probably discuss first (or maybe we can have some telco about it - but don't assume that I'd consider myself the big systemd expert ;-) so I might be of little help)

Cheers, Chris.

paulmillar commented 7 years ago

We are working on improving the systemd support, which requires some restructuring of our we structure the dCache code. In essence, we want to "pull out" the platform specific parts so that these may be maintained independently of the dCache code-base. This change will allow us to have different support scripts: ones for systemd deployments, for sys-v deployments, and for tar-ball deployments.

calestyo commented 7 years ago

One question is: will there be so many non-systemd deployments to justify them being supported?

I don't think it's easy to achieve supporting all three equally well, the problem with the config options like dcache.user is a good example for this. Logging is another.

sysvinit will simply die pretty soon in any of the major linux distros, so I personally wouldn't want to put too much effort into a dying system... and as I've said, without many ugly hacks and much inhomogeneity, I think it's barely doable to support more than one.

RHEL7 is already there and the typical production dCache site has IMO only little reason to say that they couldn't update to it (since dCache nodes are usually dedicated).

paulmillar commented 7 years ago

We will continue supporting non-systemd platforms while sites are dependent on this. To further clarify this point:

  1. Fermilab use SL6 and have no plan to migrate away at this time,
  2. NDGF are switching from packaged to tar-ball based deployments for their pool nodes.

Apart from DESY, these are the core contributors to dCache; therefore, there is absolutely no way we will drop support for non-systemd packages.

As I've already said, we have a plan on a new architecture that will provide a more structured approach to supporting all three deployments. In the mean time, we will fix problems as they are reported, and as time allowed (based on priority).

kofemann commented 1 year ago

dcache start/stop doesn't supported with systemd packages