= comes for free)
But then if some such .mount units would get unmonted remote-fs.target's
Requires= would not deactivate remote-fs.target and my
service would in turn not be deactivated
Thanks for your help
--
Thomas HUMMEL
On 2/7/24 11:50, Thomas HUMMEL wrote:
Still I cannot understand where the Requires= comes in
remote-fs.target unit as doc for special target only describes a Wants=
dep added by systemd-fstab-generator in the case of auto mounts.
Well, forget about that Wants= dep which is to the mount
On 2/6/24 17:06, Silvio Knizek wrote:
Hi Thomas,
RequiresMountsFor=3D should be your friend. It just takes a space-
separated list of paths and does all the other stuff by itself.
Hello, thanks for your reply.
Actually RequiresMountsFor is not what I need because I'd have to point
some
the mount process does not seem to be involved
in the ordering dep, or does it ?
Thanks for your help
--
Thomas HUMMEL
unning instances ?
Thanks for your help
--
Thomas HUMMEL
_INTERFACE" -o "$ACTION" != "up" ] && exit 0
[ "$INTERFACE" == "$F5_INTERFACE" -a "$ACTION" == "up" ] && echo
"$SCRIPT_NAME: adding $F5_INTERFACE nameservers to systemd-resolved
configuration"
/usr/bin/resolvectl dns $F5_INTERFACE $F5_NAMESERVER_1 $F5_NAMESERVER_2
|| { echo "Pb running resolvectl" ; usage 1 ; }
exit 0
--
Thomas HUMMEL
dispatcher
mechanism to run resolvectl at the right time without touching
resolvconf ? This would still be a workaround though.
Thanks for your help
--
Thomas HUMMEL
(yes it is green but
lists no ipv4.dns property)
$ nmcli -f GENERAL.NM-MANAGED device show tun0
GENERAL.NM-MANAGED: yes
$ nmcli -f ipv4.dns connection show tun0
ipv4.dns:
Thanks for your help
--
Thomas HUMMEL
where the specific ns <-> interface is
persited or stored or is this global updating all there is ?
Thanks for your help
--
Thomas HUMMEL
al state ?
Thanks for your help
--
Thomas HUMMEL
> On 9/9/22 18:09, Andrei Borzenkov wrote:
Hello,
maybe referring to
https://lists.freedesktop.org/archives/systemd-devel/2022-January/047342.html
would help clarify ?
--
TH
agree though that tmpfiles seems to be the most elegant way in general
to perform such things.
Thanks.
--
Thomas HUMMEL
-July/048100.html
So I rolled back to a service unit and even so I did have to order it
After= a late (custom) target
None of this was satisfactory but I did not manage to find out what
happened.
Thanks
--
Thomas HUMMEL
iginal naive setting (tmpfiles or service).
Thanks again anyway.
--
Thomas HUMMEL
On 13/07/2022 00:35, Silvio Knizek wrote:
Am Dienstag, dem 12.07.2022 um 18:55 +0200 schrieb Thomas HUMMEL:
Hi,
Hello,
thanks for your answer
first of all, no need for /sys in /etc/fstab. /sys will _always_ be
mounted by systemd.
Ok. This must be put by our image generating tool
ion I should look, if it is
systemd related at all ?
Thanks for your help
--
Thomas HUMMEL
provider know about ?
Thanks for your help
--
Thomas HUMMEL
On 15/02/2022 18:13, Lennart Poettering wrote:
On Di, 15.02.22 17:30, Thomas HUMMEL (thomas.hum...@pasteur.fr) wrote:
A passive unit is a sync point that should be pulled in by the service
that actually needs it to operate correctly. hence: ask the question whether
networkd/NetworkManager
be pulled in, correct ? So before ordering
around it one can make sure some unit pulls the checkpoint ?
Thanks for your help
--
Thomas HUMMEL
My question was that silly ? ;-)
--
Thomas HUMMEL
?
Thanks
--
Thomas HUMMEL
only Infiniband remote mounts ?
So my question would revolve around the above points
Can you help me figuring out the correct way to see those concepts ?
Thanks for your help
--
Thomas HUMMEL
'm correct, this would be the reason more than the pid 1 direct
parenthood you mentionned. Otherwise, in the standard services (not
using PAMName=) case this would work only with the type=forking
services, wouldn't it ?
Thanks for your help
--
Tho
user@.service just for the user to be able to use its own systemd
instance (which in my case of user crontab is not used) ?
I all of my guesses are correct I still have to figure out the exact
problem I had when the user (who had a crontab) was not allowed to
access systemd-user pam service.
Thanks
whereas crond semmes to need it (givent no systemd --user
was previously running in both cases) ?
Thanks for your help
--
Thomas HUMMEL
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd
On 10/14/20 8:13 PM, Andrei Borzenkov wrote:
And both sshd and crond include pam_access in their configuration?
Yes, crond has the same session incude of password-auth.
Thanks
--
Thomas HUMMEL
___
systemd-devel mailing list
systemd-devel
On 14/10/2020 13:24, Andrei Borzenkov wrote:
On Wed, Oct 14, 2020 at 11:42 AM Thomas HUMMEL wrote:
Hello,
thanks for your answer. It's getting clearer.
Still : why would the user crond runs on behalf of needs to be allowed
in access.conf to access the systemd-user service ?
My
?) such a rule in
access.conf is not needed for let's say a ssh login first session ?
Thanks for your help
--
Thomas HUMMEL
On 13/10/2020 20:05, Simon McVittie wrote:
On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote:
Ok, so for instance, on my debian, when I see:
user@1000.service
Ok so it's this service (systemd --user) which uses the systemd-user
PAM
service name ? Passed to the generic sd-pam worker ? Correct ?
Yes.
You said above that it was only at the creation of this service ?
Thanks for your help
--
Tho
what service exactly is started ? crond opening
its PAM session does not cause a systemd --user to be instanciated or
does it ? I thought the only way to have a systemd --user was through
the creation via pam_systemd notifying systemd-logind at a user fist
login (and/or to linger the user)
Thanks for
message (which makes me think about the creation of the crond session
through the systemd --user instance running a job)
Thanks for your help and sorry for the confusion
--
Thomas HUMMEL
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
Thanks for your answer
On 8/11/20 5:43 PM, Michal Sekletar wrote:
On Wed, Aug 5, 2020 at 4:12 PM Thomas HUMMEL
On RHEL/CentOS 8 biosdevname naming is not used unless it is explicitly
enabled on the kernel command line using biosdevname=1.
Indeed I've read the udev rule too fast
evious step ? What was the use of the biosdevname stop then ?
finally, what does "If the kernel claims that the name it has set for a
device is predictable" mean
(https://www.freedesktop.org/software/systemd/man/systemd.link.html#) ?
And what is the kernel name (%k) : is it alway
4 ou 5 systemctl start
rsyslog.service and only the last one succeeds corresponds to this "race
condition" you described above ?
Thanks a lot for your explanations. Makes more sense now.
--
Thomas HUMMEL
___
systemd-devel mail
but, again, without
the After= having any effect, it should not matter, should it ?
So I'm still convinces I'm missing something obvious...
Thanks for your help
--
Thomas HUMMEL
___
systemd-devel mailing list
systemd-devel@lists.freedesktop
unit will not be
started. "
That's what I meant and though it does seems so at boot, I seemed to
experience the contrary when manually starting rsyslog.service...
So I must like you said misunderstand something...
Thanks for your help
--
Tho
it at the last start command)
# ls -l /run/systemd/journal/syslog
ls: cannot access '/run/systemd/journal/syslog': No such file or directory
What am I missing ?
Note: rsyslog service is of Type notify and has a Restart value of no-fail
Thanks for your help
--
Thomas HUMMEL
On 16/06/2020 10:08, Lennart Poettering wrote:
On Mo, 25.05.20 16:19, Thomas HUMMEL (thomas.hum...@pasteur.fr) wrote:
Hello,
the point below has been buried at the end one of a previous thread. So feel
free to ignore it if you find it irrelevant.
With systemd-239 on linux 4.18.0 (CentOS
On 16/05/2020 08:16, Andrei Borzenkov wrote:
15.05.2020 12:57, Thomas HUMMEL пишет:
In other words : is it a bad practice to order a home made service
before remote-fs-pre.target ?
Why would it be? The very reason remote-fs-pre.target was added is to
allow services to be reliably started
Hello,
the point below has been buried at the end one of a previous thread. So
feel free to ignore it if you find it irrelevant.
With systemd-239 on linux 4.18.0 (CentOS 8.1), why does hostnamectl
--static set-hostname instantly sets the transient hostname to
*only* when is not the
On 14/05/2020 07:35, Andrei Borzenkov wrote:
It does not match your graphs. Your service is apparently ordered after
network-online.target (not after network.target) and startup is most
certainly initiated before rsyslog.service. Not hat it explains anything
but at least you need to provide
?
Thanks for your help
--
Thomas HUMMEL
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 5/6/20 11:51 AM, Thomas HUMMEL wrote:
On 5/4/20 3:57 PM, Thomas HUMMEL wrote:
but
hostnamectl --static set-hostname 'static' where current static
hostname is already 'static' then transient hostname is never set.
Hello,
am I wrong on this one ?
Hello, sorry to insist, I just wanted
On 5/4/20 3:57 PM, Thomas HUMMEL wrote:
but
hostnamectl --static set-hostname 'static' where current static hostname
is already 'static' then transient hostname is never set.
What do you think about it ?
Hello,
am I wrong on this one ?
Thanks for your help
--
Thomas HUMMEL
On 5/5/20 7:41 PM, Andrei Borzenkov wrote:
a) Before= does not pull anything anywhere.
Yes I know sorry I did not use the correct term. I did not mean that.
b) as you already found, by default every service is ordered after
local-fs.target. You need DefalutDependencies=no if you want to
On 5/5/20 5:27 PM, Thomas HUMMEL wrote:
On 5/5/20 5:15 PM, Thomas HUMMEL wrote:
-> this seems to be like an actual run and not only the queuing of a
job into the transaction which would be discarded afterwards when the
cycle is discovered ?
Ok I figure out this one : I was confus
On 5/5/20 5:15 PM, Thomas HUMMEL wrote:
-> this seems to be like an actual run and not only the queuing of a job
into the transaction which would be discarded afterwards when the cycle
is discovered ?
Ok I figure out this one : I was confusing the
systemd-tmpfiles-setup.service from ini
On 4/28/20 5:36 PM, Thomas HUMMEL wrote:
3) regarding local-fs dans remote-fs targets : I'm not really sure if
any fits in either passive or active units.
Hello again,
regarding local-fs.target : is it legit for a custom service unit to
pull it in with a Before=local-fs.target (no Wants
:
in particular starting from this post (the post above just show how much
I was confused)
https://mail.gnome.org/archives/networkmanager-list/2020-April/msg00031.html
of this thread
https://mail.gnome.org/archives/networkmanager-list/2020-April/msg00022.html
Thanks for your help
--
Thomas HUMMEL
y fits in either passive or active units.
I see that local-fs.target can be pulled in by sysinit.target and that
dracut-pre-pivot.target can pull in remote-fs.target but to me those 2
targets would rather fit the passive unit category ?
Thanks for your help
--
Thomas HUMMEL
__
On 4/27/20 11:51 AM, Mantas Mikulėnas wrote:
Hello, thanks for your answer.
On Mon, Apr 20, 2020 at 6:17 PM Thomas HUMMEL <mailto:thomas.hum...@pasteur.fr>> wrote:
1. why does the transient hostname change while I stated --static only
while running hostnamectl ?
2.
On 4/27/20 11:16 AM, Thomas HUMMEL wrote:
Actually, I noticed this is true when NetworkManager's hostname-mode
setting is set to 'none'. If set to 'dhcp', the transient hostname
aligns instantly to the new static one.
Sorry I may be wrong on this one as I can not reproduce it.
Thanks
--
TH
On 4/20/20 5:10 PM, Thomas HUMMEL wrote:
At this point, the transient hostname is unchanged (which is what I'd
expect) as seen with hostnamectl above or directly asking dbus:
[root@maestro-1000 ~]# dbus-send --print-reply --system
--dest=org.freedesktop.hostname1 /org/freedesktop/hostname1
not ran
it myself and NetworkManager (hostname-mode=none) does not manage the
transient hostname. It only uses this service as a proxy to get the
'original' hostname.
Thanks for your help
--
Thomas HUMMEL
___
systemd-devel mailing list
systemd
54 matches
Mail list logo
