On Tue, 18 Nov 2014 10:39:46 Gaudenz Steinlin wrote: > To me it looks very wrong because it goes back to custom scripting > (calling a command) instead of using built in systemd facilities. IMO > systemd is about getting rid of complex error prone scripts like the > ceph init script. The fact that it's possible to replace this init > script by 3 config files with 5-10 lines each is a hughe advantage > (IMHO). > > The meta service file might work now, but it looks like something bound > to bite you later.
Agreed. Meta service makes sence only for compatibility (or maybe only for
stopping everything ceph-related with one command). Native systemd services
seems to be nicer.
> >> I'm not a systemd expert but I did not find an easy way to create
> >> something like a meta-service in a way that looks like integrated into
> >> systemd. But then I don't think that's needed either. The way the
> >> current init script tries to start all the different daemons in one
> >> script always seemd odd to me. Do we need a meta service like this?
> >
> > Unfortunately we need it for compatibility. Otherwise systemd tries to
> > start SysV script and we have a mess much worse than just having no-op
> > meta service...
>
> If that's the only reason you would like to have this service file, then
> there is an easier solution. The standard way to avoid this is to
> install a service file which is a symlink to /dev/null. In other words
> "/lib/systemd/system -> /dev/null". There are various examples of this
> already in the systemd package.
Cool, we can turn it to complete no-op. It may be nice -- I didn't think of
it.
> You don't pass the hostname, you pass the id. They don't have to match.
> Passing a wrong id does not work as the daemon then does not find it's
> store. I don't think this is merley a documentation issue. I'm not even
> sure if it's possible to rename a mon.
OK...
> By default systemd only restarts 5 times and then gives up.
No it is incorrect. My OSDs are crashing like crazy and with "Restart=on-
abnormal" service restarted within seconds after failure and never give up so
it may be restarted hundred times or more.
> So permanent
> restarts are not a problem. After that the values only limit manual
> restarts. If someone has good values which are backed by evidence I
> don't have anything against changing the default. But until then I would
> just go with the systemd defaults.
Defaults couldn't be worse and I already explained why. Commented boilerplate
in "ceph-osd@.service" is closest I could get to useful restart but then I
asked myself whether restart is needed at all and couldn't produce a
definitive answer. I tend to leave restart code commented in case someone
decide to try it (or feel that it may be useful). At the moment I'm against
restart enabled by default -- this realisation comes from weeks of
experimentation.
> I can't follow your reasoning here. On one hand you think OSDs are
> unstalbe (which does not match my experience) but on the other hand you
> don't want to restart them. That seems odd to me.
Because restart is disruptive if OSD crashes right away (or shortly) after
initialisation.
> The faulty hardware argument is a good one. Is there a way to detect this?
No, there isn't.
> Do OSDs exit with
> a specific code in this case. That would be best as we could just add
> this code to the list of successful exit codes.
Is there a specific exit codes for asserts in code? No, so this is not an
option.
> >> - Mounting OSD filesystems: For sysvinit the init script mounts the OSD
> >>
> >> filesystem. None of the proposed systemd solutions mounts any
> >> filesystems.
> >
> > How did you miss "RequiresMountsFor=/var/lib/ceph/osd/ceph-%i" in my
> > "ceph-
> > osd@.service" file?
>
> I did not miss this. But this does not cause the filesystem to be
> mounted and does not stop the deamon from starting if there is no
> configuration to mount the filesystem at all, because it does not know
> about it (see below).
I'm not sure I follow you... I may have misunderstood "RequiresMountsFor"...
Would it attempt start service if RequiresMountsFor location is not mounted?
Or do you mean that mount points could be missing from fstab? I'd say that
principle of least surprise dictates that all mount points should be listed in
fstab, not mounted by some obscure logic/script...
> RequiresMountsFor=
> Takes a space-separated list of absolute paths. Automatically adds
> dependencies of type Requires= and After= for all mount units required to
> access the specified path.
>
> Mount points marked with noauto are not mounted automatically and will be
> ignored for the purposes of this option. If such a mount should be a
> requirement for this unit, direct dependencies on the mount units may be
> added (Requires= and After= or some other combination).
I'm still not sure I understand how systemd works and what's your plan...
> This means you don't have to list the mount points. Systemd is clever
> enough to figure out what it has to mount to make the directory
> available.
> But this only works if all relevant filesystems are
> configured as mount units. Either by adding them to /etc/fstab or by
> adding explicit mount units for them.
An unrelated example just comes to mind... I have Btrfs sitting on three
crtptdisks and systemd is stupid enough to fail to find /dev/disk/by-label
after when all needed devices are luks-opened... It just waits for 1.5 min. on
boot and I have to log-in and do "mount -av" to mount remaining mount point.
It was working perfectly before systemd. No, systemd is not clever... :(
--
Cheers,
Dmitry Smirnov.
---
A man is his own easiest dupe, for what he wishes to be true he
generally believes to be true.
-- Demosthenes, Third Olynthiac, sct. 19 (349 BCE)
signature.asc
Description: This is a digitally signed message part.
