Re: [systemd-devel] Requires and After
On Wed, Jan 2, 2019 at 10:09 PM James Feeney wrote:
> On 1/2/19 3:21 AM, Reindl Harald wrote:
>>
>> it's pretty obvious when i REQUIRE something that it should be there
>> when i get started
>
> Not only is it not "obvious" that "something should be there", it is not true.
>
> You are confusing "Requires=" and "Requisite=".
>
> Some developers and some users are not native English speakers. In
> some cases, systemd terminology can be ... less than optimal, while,
> in other situations, users will simply misunderstand the conventional
> meaning of words.
You might not like how "Requisite=" is defined in systemd but that
doesn't mean that it's wrong or "less than optimal."
If a.service has "Requires=b.service" and b.service isn't started,
then b.service is started.
If a.service has "Requisite=b.service" and b.service isn't started
(and a.service fails).
What Reindl Harald was saying was that "Requires" should have an
implicit "After" because it wouldn't make sense for a.service to
require b.service but to start before b.service.
However, IIRC and IIUC, someone suggested a weird example where
- a.service can function without b.service being up and there's a
desire for b.service to start when a.service is started
- b.service cannot function without a.service being up
and where you'd therefore need "Wants=b.service" and
"Before=b.service" in a.service
You could even replace "Wants=" by "Requires=" if a.service can launch
without b.service being up but cannot function without b.service being
up.
Using "BindsTo=" ("PartOf=") in b.service rather than "Wants="
("Requires=") in a.service seems more intuitive to me from the
"Before"/"After" perspective.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabling tomcat8
On Wed, Dec 20, 2017 at 5:39 PM, Jonathan de Boyne Pollard wrote: > Tom H: > >> The usual reason for not having a native unit is that you can't force >> developers to do that work. > > Psst! This discussion is predicated upon a falsehood. There is an > abundance of service units for Tomcat, and has been for years. They > are part of the systemd House of Horror. Sad to say: M. Westerhof has > already found two of those. Feel free to email debian-devel@ that maintainers ought to include systemd units in all of their packages by grabbing ready-made units elsewhere. Good luck. This isn't how it worls. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabling tomcat8
On Wed, Dec 20, 2017 at 8:59 AM, Reindl Harald wrote: > Am 20.12.2017 um 14:52 schrieb Tom H: >> On Tue, Dec 19, 2017 at 2:34 PM, Reindl Harald >> wrote: >>> in 2017 it shpuld be a native systemd-unit but from where comes the >>> "vendor preset: enabled" in case of a generated unit? >> >> The usual reason for not having a native unit is that you can't force >> developers to do that work. Also, some sysvrc scripts are so >> convoluted that the developers prefer to let the generator take care >> of business > > in doubt where is the problem to point ExecStart/Stop to the > elsewehere located sysv-initscript even without change that? That's what the sysv generator does. If you're going to write a unit, you may as well write a "proper" one. > the benefit is that you still have the > /etc/systemd/system/servicename.service.d snippets and can use namespace > options like ReadOnlyDirectory and so on as well as override/disable/enable > works proper for around 10 minutes of work > > guess what Fedora did with "iptables.service" I'd guess that it was more about keeping non-standard verbs, like "save", than anything else. > so no, i don't see an excuse after that many years for crap within > /etc/init.d/ I doubt that distributions using a generator for sysvrc scripts agree with you - or they've have systemd units for everything. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabling tomcat8
On Tue, Dec 19, 2017 at 2:34 PM, Reindl Harald wrote: > Am 19.12.2017 um 20:05 schrieb Lennart Poettering: >> On Mo, 18.12.17 19:40, Cecil Westerhof (cldwester...@gmail.com) wrote: >>> There is a system with tomcat8 installed and enabled. At the moment it is >>> not used, so I thought it better to disable it. >>> >>> When I enter: >>> systemctl disable tomcat8.service >>> >>> I get: >>> tomcat8.service is not a native service, redirecting to >>> systemd-sysv-install. >>> Executing: /lib/systemd/systemd-sysv-install disable tomcat8 >> >> This means the service in question is not a native systemd service, >> but a legacy SysV service, that is only hooked in with distro-specific >> shell glue. If that doesn't work it's not an upstream issue, you need >> to contact your downstream distribution for help, as they put together >> the shell script glue > > in 2017 it shpuld be a native systemd-unit but from where comes the "vendor > preset: enabled" in case of a generated unit? The usual reason for not having a native unit is that you can't force developers to do that work. Also, some sysvrc scripts are so convoluted that the developers prefer to let the generator take care of business. > Loaded: loaded (/etc/init.d/tomcat8; generated; vendor preset: enabled) It's standard for generated units: root@1604 ~ # systemctl status apparmor.service ● apparmor.service - LSB: AppArmor initialization Loaded: loaded (/etc/init.d/apparmor; bad; vendor preset: enabled) Active: active (exited) since Wed 2017-12-20 08:27:53 EST; 10min ago Docs: man:systemd-sysv-generator(8) Process: 274 ExecStart=/etc/init.d/apparmor start (code=exited, status=0/SUCCESS) Dec 20 08:07:02 1604 systemd[1]: Starting LSB: AppArmor initialization... Dec 20 08:07:03 1604 apparmor[274]: * Starting AppArmor profiles Dec 20 08:27:53 1604 apparmor[274]:...done. Dec 20 08:27:53 1604 systemd[1]: Started LSB: AppArmor initialization. root@1604 ~ # ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process
On Fri, Nov 11, 2016 at 4:13 PM, Michael Hirmke wrote: > > Does anyone know, what "+::" in /etc/passwd means? Users in the nis (by default) or nisplus db will be valid on that system if you have "compat" on the "passwd" line of "/etc/nsswitch.conf". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Samba Server dosen't start
On Sun, Jun 26, 2016 at 8:09 AM, Reindl Harald wrote: > Am 26.06.2016 um 13:27 schrieb Ralf Recktenwald: >> >> Smb.conf > > how is that a systemd problem? > > how do you imagine help without mention distrubition, software-versions, > cotent of the systemd-unit, systemctl status servicename and so on? The problem's this journalctl output: "Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel"; [Of course, at least the units (or sysvinit scripts) are needed, no matter what list's used] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Variables in the [Unit] section of a server
On Thu, Jan 14, 2016 at 3:58 PM, Lennart Poettering
wrote:
> On Wed, 13.01.16 10:51, Steve Dickson (ste...@redhat.com) wrote:
>>
>> Is is possible to set a variable in the [Unit]
>> section of a service?
>>
>> For example in rpc-gssd.service there is
>> ConditionPathExists=/etc/krb5.keytab
>>
>> but for some installation the krb5.keytab
>> is in a different place. The rpc.gssd daemon
>> can be told this by setting a command line
>> argument from the EnvironmentFile.
>>
>> So people have to edit both the EnvironmentFile
>> and the rpc-gssd.service to make this change.
>>
>> So it would be nice if only the EnvironmentFile
>> need to be edit and the change would happen
>> in both places.
>>
>> Possible?
>
> Unit files are supposed to be configuration files, people can override
> and extend if they want to make changes. It's not recommended to use
> the EnvironmentFile= logic to externalise configuration. Instead, just
> keep the config in one place, in the unit files, to make things less
> opaque and more uniform.
>
> And no, unit files are not supposed to be a templating language and do
> not support generlized variable expansion and quite frankly I should
> never even have added the limited env var expansion via
> EnvironmentFile= that ExecStart= supports, since it invites people to
> externalise settings that way.
I understand that you'd prefer that we use drop-ins to set
"Environment=Foo=bar" or override "ExecStart=..." and it probably
works for most daemons - and should also be non-distro-specific.
But in the case of nfs, it would mean more messing around for admins
because there are many variables to set.
This is on Ubuntu 16.04 but RHEL and Fedora are similar because the
units are from upstream and distros simply have to modify
"/usr/lib/systemd/scripts/nfs-utils_env.sh":
root@localhost:/lib/systemd/system# grep Start= nfs-* rpc-*
nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS
nfs-config.service:ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh
nfs-idmapd.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
nfs-kernel-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
nfs-utils.service:ExecStart=/bin/true
rpc-gssd.service:ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
rpc-statd-notify.service:ExecStart=-/sbin/sm-notify $SMNOTIFYARGS
rpc-statd.service:ExecStart=/sbin/rpc.statd --no-notify $STATDARGS
rpc-svcgssd.service:ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
root@localhost:/lib/systemd/system# grep Env nfs-* rpc-*
nfs-idmapd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-kernel-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-mountd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-gssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-statd-notify.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-statd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-svcgssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
root@localhost:/lib/systemd/system#
nfs-config.service runs "/usr/lib/systemd/scripts/nfs-utils_env.sh",
which sources "/etc/default/nfs-{common,kernel-server}"
("/etc/sysconfig/nfs" on RHEL and Fedora) and generates
"/run/sysconfig/nfs-utils". Setting the variables unit-by-unit would
be a PitA.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
