Re: [systemd-devel] Submitting a service activation to remote mounts success

[Silvio Knizek]

Am Dienstag, dem 06.02.2024 um 16:15 +0100 schrieb Thomas HUMMEL:
> Hello,
>=20
> I'm using systemd-239-74 on RHEL 8.8 EUS.
>=20
> I was wondering if one can express the following :
>=20
> start some service *only and only if/when* all remote mounts (ex: nfs,=
=20
> some parallel fs) has *succeeded*, taking into account it may take some=
=20
> time for some mount (some fs clients just live curl | sh themselves at=
=20
> start !) to finish (which seems to exlude usage of=20
> AssertPathIsMountPoint for instance, as it would not wait, or would it ?)
>=20
> I have no auto option in the fstab for those fs and they use the _netdev=
=20
> option
>=20
> Obvisouly I could statically list all the mounts units as an ordering=20
> dependency but this is not what I was looking for as there are namy (and=
=20
> I'm not even sure - see below - it it would be enough)
>=20
> Exploring this question I stumbled upon the following points :
>=20
> my understanding is that:
>=20
> 1. remote-fs.target special target is pulled in by multi-user.target and=
=20
> is added by systemd-fstab-generator as a Before=3D ordering dep to all=
=20
> remote .mount units
>=20
> -> I also see a remote-fs.target has a Requires=3D=20
> activation dep : I probably missed it in the doc but I don't see this=20
> listed in neither implicit nor default dep : where does it come from ?
>=20
> 2. Before=3D/After=3D refer, in the case of service units, to when the un=
it=20
> has "finished starting up", this being defined by "when it returns=20
> failed or success", which is dependent of the Type=3D of the service
>=20
> Is this understanding correct ?
>=20
> But when the unit is of type mount : what's the semantic of Before/After=
=20
> ? (I don't think I saw it in the doc neither)
>=20
> What's the meaning/use of Type=3Dnone in a .mount unit ?
>=20
> My experience is that the mount may fail and remote-fs.target will still=
=20
> be reached, even if one replace Requires with BindsTo, correct ?
>=20
> So success or failure of the mount process does not seem to be involved=
=20
> in the ordering dep, or does it ?
>=20
> Thanks for your help

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.

Another options would be to switch to x-systemd.automount in fstab for
the network shares, so they will be mounted on first access, not
necessary during early boot when there is no network.

BR
Silvio

Re: [systemd-devel] Starting a service before any networking

[Silvio Knizek]

Am Mittwoch, dem 27.09.2023 um 10:31 +0100 schrieb Mark Rogers:
> On Wed, 27 Sept 2023 at 10:18, Mantas Mikulėnas 
> <[graw...@gmail.com](mailto:graw...@gmail.com)> wrote:
> 
> > So now I'm curious: if the first command you run is to bring the interface 
> > *down*, then what exactly brought it up?
> 
> 
> Good question. The reason for down/up was that this was working as a way to 
> reset the connection after boot, so I just transferred that to the 
> ExecStartPre.
> 
> Looking at the "journalctl -u dhcpcd" output, this is what I see from my last 
> boot:  
> Feb 14 10:12:05 pi systemd[1]: Starting dhcpcd on all interfaces...  
> Feb 14 10:12:05 pi ip[372]: 2: eth0:  mtu 1500 qdisc 
> noop state DOWN group default qlen 1000  
> Feb 14 10:12:05 pi ip[372]:     link/ether b8:27:eb:0d:ee:bb brd 
> ff:ff:ff:ff:ff:ff  
> Feb 14 10:12:05 pi ip[383]: 2: eth0:  mtu 
> 1500 qdisc pfifo_fast state DOWN group default qlen 1000  
> Feb 14 10:12:05 pi ip[383]:     link/ether b8:27:eb:0d:ee:bb brd 
> ff:ff:ff:ff:ff:ff  
> Feb 14 10:12:06 pi dhcpcd[385]: wlan0: starting wpa_supplicant  
> Feb 14 10:12:36 pi dhcpcd[385]: timed out  
> Feb 14 10:12:36 pi systemd[1]: Started dhcpcd on all interfaces.  
> Feb 14 10:12:37 pi systemd[1]: Stopping dhcpcd on all interfaces...  
> Feb 14 10:12:37 pi dhcpcd[519]: sending signal TERM to pid 466  
> Feb 14 10:12:37 pi dhcpcd[519]: waiting for pid 466 to exit  
> Feb 14 10:12:38 pi systemd[1]: dhcpcd.service: Succeeded.  
> Feb 14 10:12:38 pi systemd[1]: Stopped dhcpcd on all interfaces.  
> Feb 14 10:12:38 pi systemd[1]: Starting dhcpcd on all interfaces...  
> Feb 14 10:12:38 pi ip[524]: 2: eth0:  mtu 
> 1500 qdisc pfifo_fast state DOWN group default qlen 1000  
> Feb 14 10:12:38 pi ip[524]:     link/ether b8:27:eb:0d:ee:bb brd 
> ff:ff:ff:ff:ff:ff  
> Feb 14 10:12:38 pi ip[529]: 2: eth0:  mtu 
> 1500 qdisc pfifo_fast state UP group default qlen 1000  
> Feb 14 10:12:38 pi ip[529]:     link/ether b8:27:eb:0d:ee:bb brd 
> ff:ff:ff:ff:ff:ff  
> Feb 14 10:12:38 pi dhcpcd[530]: wlan0: starting wpa_supplicant  
> Feb 14 10:12:49 pi dhcpcd[530]: Too few arguments.  
> Feb 14 10:12:49 pi dhcpcd[530]: Too few arguments.  
> Feb 14 10:12:49 pi systemd[1]: Started dhcpcd on all interfaces.
> 
>  (I deleted the "ip addr" output from the interfaces other than eth0 for 
> brevity.) 
> 
> The interesting thing is surely that dhcpcd is being started twice. Assuming 
> that was always happening then that suggests dhcpcd was bringing the network 
> up early (and failing but leaving it in a "stuck" state) and then again later 
> (where it was unable to recover from the first failure, but now can)?

Why does this sounds like https://github.com/raspberrypi/linux/issues/3195? 
Maybe you find starting there some more information.

BR  
Silvio

Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named

[Silvio Knizek]

Hi Marc,

why is it suggested to run `named` within its own chroot? For security reasons? 
This can be achieved much easier with systemd native options.

Something like

`/etc/systemd/system/named.service`

```ini
[Unit]
Description=Internet domain name server
After=network.target

[Service]
Type=notify
User=named
DynamicUser=true
ExecStart=/usr/bin/named -f -c /etc/named/named.conf
ExecReload=/usr/bin/kill -HUP $MAINPID
NoExecPaths=/
ExecPaths=/usr/bin/named /usr/bin/kill
AmbientCapabilities=CAP_NET_BIND_SERVICE
ProtectSystem=full
ProtectHome=yes
RuntimeDirectory=%p
StateDirectory=%p
CacheDirectory=%p
LogsDirectory=%p
ConfigurationDirectory=%p

[Install]
WantedBy=multi-user.target
```

Make sure `directory` in `/etc/named/named.conf` points to `/var/lib/named`.

Further security considerations may apply. Testing is necessary.

BR  
Silvio

Re: [systemd-devel] VirtualBox VM as a unit failures

[Silvio Knizek]

Am Donnerstag, dem 01.09.2022 um 19:17 -0300 schrieb Sergio Belkin:
> 
> 
> 
> El jue, 1 sept 2022 a las 16:22, Silvio Knizek
> () escribió:
> > Am Donnerstag, dem 01.09.2022 um 14:59 -0300 schrieb Sergio Belkin:
> > > 
> > > This is the unit file:
> > > [Unit]
> > > Description=VirtualBox VM %i
> > > After=network.target vboxdrv.service
> > > Before=runlevel2.target shutdown.target
> > > 
> > > [Service]
> > > Type=forking
> > > Restart=no
> > > TimeoutSec=5min
> > > IgnoreSIGPIPE=no
> > > KillMode=process
> > > GuessMainPID=no
> > > RemainAfterExit=no
> > > 
> > > #ExecStart=/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --
> > > startvm
> > > f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config 
> > > ExecStart=/usr/bin/VBoxManage startvm %i --type headless
> > > ExecStop=/usr/bin/VBoxManage controlvm %i acpipowerbutton
> > > 
> > > [Install]
> > > WantedBy=default.target
> > > 
> > > (End of file)
> > > 
> > > What is the proper way to configure this kind of unit?
> > > 
> > > Thanks in advance
> > > 
> > Is this really a forking process? Or do you just instruct some
> > daemon
> > via a RPC call to start your VM? In this case no actuall process
> > would
> > be there.
> > If there is a forking process, can you instruct VBoxManage to run
> > in
> > the foreground?
> > Or do you need to start some daemon process first and if not
> > already
> > running, than VBoxManage does so? This would explain the lingering
> > processes.
> > In generall your KillMode=process is what keeps the other processes
> > running in the cgroup. Just remove it.
> > 
> > Also, your Before= line is bogus. And if your vboxdrv.service just
> > contains the lines to load the vbox modules, you would be far
> > better of
> > with some snippet in /etc/modules-load.d
> > 
> > Oh, and as you run in user mode, _all_ your Before= and After=
> > entries
> > are useless, as user units can't see and reference system units.
> > 
> > So yeah, your goal would be to see how you can actually start the
> > VM
> > process via CLI and nothing else.
> > 
> > BR
> > Silvio
> 
> Hi Silvio,
> Nice answer.
> How to tell if it is a forking process?
> The command  "/usr/bin/VBoxManage startvm RHEL7  --type headless"
> exits  and then it runs "/usr/bin/VBoxManage startvm RHEL7  --type
> headles"
> 
> Thanks again!

Hi,

please keep answers on-list.
For your message, I don't understand it. The command forks/exists and
runs itself? Or did you copy it wrong the second time? Has VBoxManage
other command line parameters you can use for _not_ forking?

Re: [systemd-devel] VirtualBox VM as a unit failures

[Silvio Knizek]

Am Donnerstag, dem 01.09.2022 um 14:59 -0300 schrieb Sergio Belkin:
> 
> This is the unit file:
> [Unit]
> Description=VirtualBox VM %i
> After=network.target vboxdrv.service
> Before=runlevel2.target shutdown.target
> 
> [Service]
> Type=forking
> Restart=no
> TimeoutSec=5min
> IgnoreSIGPIPE=no
> KillMode=process
> GuessMainPID=no
> RemainAfterExit=no
> 
> #ExecStart=/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --startvm
> f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config 
> ExecStart=/usr/bin/VBoxManage startvm %i --type headless
> ExecStop=/usr/bin/VBoxManage controlvm %i acpipowerbutton
> 
> [Install]
> WantedBy=default.target
> 
> (End of file)
> 
> What is the proper way to configure this kind of unit?
> 
> Thanks in advance
> 
Is this really a forking process? Or do you just instruct some daemon
via a RPC call to start your VM? In this case no actuall process would
be there.
If there is a forking process, can you instruct VBoxManage to run in
the foreground?
Or do you need to start some daemon process first and if not already
running, than VBoxManage does so? This would explain the lingering
processes.
In generall your KillMode=process is what keeps the other processes
running in the cgroup. Just remove it.

Also, your Before= line is bogus. And if your vboxdrv.service just
contains the lines to load the vbox modules, you would be far better of
with some snippet in /etc/modules-load.d

Oh, and as you run in user mode, _all_ your Before= and After= entries
are useless, as user units can't see and reference system units.

So yeah, your goal would be to see how you can actually start the VM
process via CLI and nothing else.

BR
Silvio

Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails

[Silvio Knizek]

Am Dienstag, dem 12.07.2022 um 18:55 +0200 schrieb Thomas HUMMEL:
> Hello,
> 
> I'm using systemd-239-45 on RHEL 8.4 x86_64 AMD nodes on which I disable 
> Turbo Core/Turbo Boost by writing '0' into the following file:
> 
> /sys/devices/system/cpu/cpufreq/boost
> 
> I want it to be disabled automatically at boot. For that matter I tried 
> 3 different ways (only one at a time)
> 
> 1) a service unit configured like this:
> 
> [Unit]
> Description=Disable CPU Turbo Boost
> 
> 
> [Service]
> # using tee here to have an output in journalctl to understand when this 
> service
> # fails to start
> ExecStart=/bin/sh -c "/usr/bin/echo 0 | /bin/tee 
> /sys/devices/system/cpu/cpufreq/boost"
> ExecStop=/bin/sh -c "/usr/bin/echo 1 | /bin/tee 
> /sys/devices/system/cpu/cpufreq/boost"
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=sysinit.target
> 
> 2) adding an entry for systemd-tmpfiles-setup.service like this:
> 
> w /sys/devices/system/cpu/cpufreq/boost - - - - 0
> 
> 3) using modprobe.d like this:
> 
> install acpi_cpufreq  /sbin/modprobe --ignore-install acpi_cpufreq 
> $CMDLINE_OPTS && echo 0 > /sys/devices/system/cpu/cpufreq/boost
> 
> 
> I noticed that *sometimes* using 1) or 2) 
> /sys/devices/system/cpu/cpufreq/boost ended up with '1' instead of '0'
> 
> I didn't see any error in journal for 2) (tmpfiles.d option) and for 1) 
> (systemd service) I saw:
> 
> 
> Jul 04 15:06:25  systemd[1]: Started Disable CPU Turbo Boost.
> Jul 04 15:06:25  sh[2788]: /bin/tee: 
> /sys/devices/system/cpu/cpufreq/boost: Permission denied
> Jul 04 15:06:25  sh[2788]: 0
> Jul 04 15:06:25  systemd[1]: disable-cpu-turboboost.service: Main 
> process exited, code=exited, status=1/FAILURE
> Jul 04 15:06:25  systemd[1]: disable-cpu-turboboost.service: Failed 
> with result 'exit-code'.
> 
> I did not manage to find out if there were a race condition and if so 
> what ordering dependencies should be stated.
> I tried to compare a "working" and "not working" systemd-analyse output 
> but I did not find anything obvious (at least for me)
> 
> Besides, /sys is mounted in the fstab (as expected)
> 
> sysfs   /sys sysfsdefaults   0 0
> 
> is there a corresponding transient .mount unit somewhere ?
> 
> Notes:
> 
> a) SELinux is disabled
> 
> b) I don't think any other service or process is touching the 
> /sys/devices/system/cpu/cpufreq/boost file
> 
> c) in the event the system boot up with the wrong value, manually echo 0 
> into the file (which exists) always work
> 
> Can you help me figuring in what direction I should look, if it is 
> systemd related at all ?
> 
> Thanks for your help
> 
> --
> Thomas HUMMEL

Hi,

first of all, no need for /sys in /etc/fstab. /sys will _always_ be
mounted by systemd.

Second, this sounds really depending on your used driver (acpi, amd, or
intel). Check out the documentation at
https://docs.kernel.org/admin-guide/pm/cpufreq.html and always check
the Arch wiki https://wiki.archlinux.org/title/CPU_frequency_scaling as
well.

Question I have is: why do you want to disable boosting?

BR
Silvio


signature.asc
Description: This is a digitally signed message part

Re: [systemd-devel] unable to attach pid to service delegated directory in unified mode after restart

[Silvio Knizek]

Am Montag, dem 21.02.2022 um 22:16 +0100 schrieb Felip Moll:
> Silvio,
>
> As I commented in my previous post, creating every single job in a
> separate slice is an overhead I cannot assume.
> An HTC system could run thousands of jobs per second, and doing extra
> fork+execs plus waiting for systemd to fill up its internal
> structures and manage it all is a no-no.
And how about an xinitd style daemon, excepting connections and
spawning processes that way?
So instead of sgamba1.service you would have a sgamba1@.service and a
sgamba1.socket, spawning sgamba1@user1.service, sgamba1@user2.service,
etc. units.
So even if one user process dies, nothing else dies. And the setup
overhead would only be once everytime a user creates a new connection.
So they can still drop their one million jobs and you has still user
isolation.

Re: [systemd-devel] unable to attach pid to service delegated directory in unified mode after restart

[Silvio Knizek]

Am Montag, dem 21.02.2022 um 18:07 +0100 schrieb Felip Moll:
> The hard requirement that my project has is that processes need to
> live even if the daemon who forked them dies.
> Roughly it is how a batch scheduler works: one controller sends a
> request to my daemon for launching a process in the name of a user,
> my daemon forks-exec it. At some point my daemon can be stopped,
> restarted, upgraded, whatever but the forked processes need to always
> be alive because they are continuing their work. We are talking here
> about the HPC world.
You could invoke a man:systemd-run for each new process. Than you can
put every single job in a seperate .slice with its own
man:systemd.resource-control applied.
This would also mean that you don't need to compile against libsystemd.
Just exec() accordingly if a systemd-system is detected.

BR
Silvio

Re: [systemd-devel] [systemd‑devel] Q: Perform action for reboots happen too frequently?

[Silvio Knizek]

Am Freitag, dem 18.02.2022 um 09:52 +0100 schrieb Ulrich Windl:
> > >
> Thanks Silvio!
>
> That looks like I was after. But admitted: I had expected that
> systemd could
> do some of the "shell scripting magic" (like counting and comparing).
>
> Regards,
> Ulrich
Well, counting and comparing goes into the area of turing completness,
doesn't it? So not having this inside systemd makes the whole system
just easier.

Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Q: Perform action for reboots happen too frequently?

[Silvio Knizek]

Am Donnerstag, dem 17.02.2022 um 10:50 +0100 schrieb Ulrich Windl:
> > > > Lennart Poettering  schrieb am
> > > > 16.02.2022 um 18:17
> in
> Nachricht :
> > On Mi, 16.02.22 14:09, Ulrich Windl
> > (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> > > Hi!
> > >
> > > I wonder: Is it possible with systemd to detect multiple reboots
> > > within a specific time interval, and react, like executing some
> > > systemctl command (that is expected to "improve" things)?  With
> > > "reboots" I'm mainly thinking of unexpected boots, not so much
> > > the
> > > "shutdown ‑r" commands, but things like external resets, kernel
> > > panics, watchdog timeouts, etc.
> >
> > The information why a system was reset is hard to get. Some
> > watchdog
> > hw will tell you if it was recently triggered, and some expensive
> > hw
> > might log serious errors to the acpi pstore stuff, but it's all
> > icky
> > and lacks integration.
>
> Lennart,
>
> you got me wrong: I don't want to filter on the reasons of the
> (re)boot, but I
> just wanted to rule out any possible solution that stores information
> during an
> orderly shutdown/reboot ;-)
>
> >
> > A safe approach would probably to instead track boots where the
> > root
> > fs or so is in dirty state. Pretty much all of today's file systems
> > track that.
>
> In the past (when there are a few logins only) I would have been
> tempted to
> use "last" to grep for boots, but if there are many (automated)
> logins, those
> boots may be "rolled out" and thus won't be counted possibly.
>
> >
> > It sounds like an OK feature to add to the systemd root fs mount
> > logic
> > to check for the dirty flag before doing that and then using that
> > is
> > hint to boot into a target other than default.target that could
> > then
> > apply further policy (and maybe then go on to enter
> > default.target).
> >
> > TLDR: nope, this does not exist yet, but parts of it sound like
> > worthwile feature additions to systemd.
>
> Something very primitive:
> a) Increment some counter on every boot, and reset that counter after
> some
> time.
> b) Check the counter and if it is >= some threshold, execute a one-
> shot
> command
>
> Could systemd help with a) and b)?
>
> Regards,
> Ulrich

Hi Ulrich,

so, incrementing a counter and executing stuff should be easy.
Something like

--- boot-counter.service
[Unit]
Description=Incrementing the boot counter
RequiresMountsFor=/var/lib
DefaultDependencies=no

[Service]
Type=oneshot
Environment="T=5"
ExecStart=/usr/bin/bash -c 'declare -i c="$(< /var/lib/boot.counter)"; c+=1; 
echo "$c" > /var/lib/boot.counter'
ExecStart=/usr/bin/bash -c 'if (($(< /var/lib/boot.counter) > T)); then 
/clean-script.sh; fi'

[Install]
WantedBy=multi-user.target
---

For the reset you can employ a .timer and a .service

--- reset-boot-counter.timer
[Unit]
Description=Reset boot counter after 30 minutes

[Timer]
OnBoot=30m
AccuracySec=1us

[Install]
WantedBy=timer.target
---

--- reset-boot-counter.service
[Unit]
Description=Set /var/lib/boot.counter to zero
RequiresMountsFor=/var/lib

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c 'echo "0" > /var/lib/boot.counter
---

HTH
Silvio

Re: [systemd-devel] PIDFile creation logic

[Silvio Knizek]

Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
> I just installed the new-to-EPEL ndppd service and am seeing this in my log:
>
> Oct 17 21:10:08 saruman systemd: Can't open PID file
> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
>
> Examining the source, I see that the pidfile is created by the child
> process, not the parent. I'm guessing that systemd is expecting the pidfile
> to exist when the parent exits? (I want to file the issue on the upstream
> program and want to make sure I understand how this should work.)
>
> Source in question. Note how daemonize() forks and exits and main() invokes
> daemonize and then creates the pidfile. I'm thinking that daemonize()
> should create the pidfile before it invokes exit().
>
> 
>
Hi,

just don't demonize and don't use a PIDFile= at all. systemd is
actually quite apt in figuring out which process is the right main one.
Also, the ndppd 0.2.5 release is 10 years old and doesn't look
maintained anymore.
OTOH, systemd-networkd itself has inbuilt NDPProxy capabilities.

BR
Silvio

Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

[Silvio Knizek]

Am Mittwoch, dem 07.07.2021 um 15:21 +0200 schrieb Christian Rohmann:
> Hello systemd-devel,
>
>
> we recently replaced a broken drive on a server and ran into a strange
> issue in regards to a mount 
>
>
>
> 1) It started with the old device not being reachable anymore and
> therefore the crypt setup and mount was just failing:
>
> --- cut ---
> [...]
>
> Jul  2 03:41:11 myserver systemd[1]:
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device:
> Job
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device/start
> timed out.
> Jul  2 03:41:11 myserver systemd[1]: Timed out waiting for device
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device.
> Jul  2 03:41:11 myserver systemd[1]: Dependency failed for Cryptography
> Setup for ee386599-8235-4d4d-9d3e-901ccf2eed4b_crypt.
> Jul  2 03:41:11 myserver systemd[1]:
> systemd-cryptsetup@ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b_crypt.service:
> Job
> systemd-cryptsetup@ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b_crypt.service/start
> failed with result 'dependency'.
> Jul  2 03:41:11 myserver systemd[1]:
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device:
> Job
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device/start
> failed with result 'timeout'.
> Jul  2 03:41:11 myserver systemd[1]:
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device:
> Job
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device/start
> timed out.
> Jul  2 03:41:11 myserver systemd[1]: Timed out waiting for device
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device.
> Jul  2 03:41:11 myserver systemd[1]: Dependency failed for
> /var/lib/ceph/osd/ceph-64.
> Jul  2 03:41:11 myserver systemd[1]: var-lib-ceph-osd-ceph\x2d64.mount:
> Job var-lib-ceph-osd-ceph\x2d64.mount/start failed with result 'dependency'.
> Jul  2 03:41:11 myserver systemd[1]:
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device:
> Job
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device/start
> failed with result 'timeout'.
>
> [...]
> --- cut ---
>
>
> 2) We then replaced the drive, created a new Luks device and created a
> new XFS filesystem on top of it.
>
>
> 3) We then updated the fstab to point to the new device name (ceph-$UUID
> of the new luks device) and triggered am immediate "mount" via Ansible
> The fstab entry now looks like this:
>
> --- cut ---
> /dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
> /var/lib/ceph/osd/ceph-64 xfs nofail 0 0
>
> --- cut ---
>
>
> and the systemd auto-generated mount unit like so:
>
> --- cut ---
>
> # /run/systemd/generator/var-lib-ceph-osd-ceph\x2d64.mount
> # Automatically generated by systemd-fstab-generator
>
> [Unit]
> SourcePath=/etc/fstab
> Documentation=man:fstab(5) man:systemd-fstab-generator(8)
>
> [Mount]
> Where=/var/lib/ceph/osd/ceph-64
> What=/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
> Type=xfs
> Options=nofail
> --- cut ---
>
>
> What happend was, that the mount succeeded initially, but then systemd
> unmounted the path right away,
> apparently because the old (auto-generated) mount unit was still
> present, in "inactive" state:
>
> --- cut ---
>
> Jul  2 13:17:04 myserver ansible-mount: Invoked with
> src=/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
> path=/var/lib/ceph/osd/ceph-64 fstype=xfs state=mounted opts=nofail
> boot=True backup=False dump=None fstab=None passno=None
> Jul  2 13:17:04 myserver kernel: [367734.361658] XFS (dm-25): Mounting
> V5 Filesystem
> Jul  2 13:17:04 myserver kernel: [367734.373636] XFS (dm-25): Ending
> clean mount
> Jul  2 13:17:04 myserver systemd[1]: var-lib-ceph-osd-ceph\x2d64.mount:
> Unit is bound to inactive unit
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device.
> Stopping, too.
> Jul  2 13:17:04 myserver systemd[1]: Unmounting /var/lib/ceph/osd/ceph-64...
> Jul  2 13:17:05 myserver systemd[1]: Unmounted /var/lib/ceph/osd/ceph-64.
> Jul  2 13:17:05 myserver kernel: [367734.413530] XFS (dm-25): Unmounting
> Filesystem
>
> --- cut ---
>
>
>
> I did find the issue https://github.com/systemd/systemd/issues/1741
> which sounds quite similar, but that is closed for comments unfortunately.
> There a supposed "workaround" apparently is to call "systemd
> daemon-reload" prior to mounting? Is this the proper way to update the
> auto-generated mount-units then?
>
> Or did we handle this whole process of replacing a device and then
> having a new one mounted at the same mount point wrong in any way?
> As explained, we were not handling any systemd mount units directly, but
> only modified the fstab.
>
>
>
> Thanks and with kind Regards
>
>
> Christian
Hi Christian,

after touching /etc/fstab you're supposed to run `systemctl daemon-
reload` to re-trigger the generators. This is in fact a feature to
announce changes in configuration files to 

Re: [systemd-devel] sibling DNS lookup of nspawn containers

[Silvio Knizek]

Am Freitag, dem 18.06.2021 um 14:52 -0700 schrieb Johannes Ernst:
>
> Thanks, Silvio, but no luck:
>
> I have host, container a and container b.
>
> In both containers, .network for host0 has LLMNR=yes in the [Network]
> section
>
> The host has LLMNR=yes in the [Resolve] section of
> /etc/systemd/resolved.conf
>
> On the host: “resolvectl query a” and “…b” works.
>
> In the containers “resolvectl query a” works only in container a, not
> in b, and vice versa. So no sibling lookup.
>
> iptables and ip6tables show default rules for all three.
>
> What am I missing?
>
> Thanks,
>
> Johannes.
>
Hi Johannes,

Are both machines in the same network zone or attached to the same
bridge interface on the host machine? Else the default NAT rules won't
allow for multicast traffic as it is done by LLMNR.
sd-nspawn uses nftables, not iptables. You should see some rules with
»nft list table ip io.systemd.nat«.
So add »--network-zone=some-fancy-name« to your systemd-nspawn
commands.

=== man: systemd.nspawn ===
Using --network-zone= is hence in most cases fully automatic and
sufficient to connect multiple local containers in a joined broadcast
domain to the host, with further connectivity to the external network.
=== ===

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Reloading configuration after mount unit

[Silvio Knizek]

Am Freitag, dem 18.06.2021 um 19:48 +0200 schrieb Norbert Lange:
> Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek
:
> >
> > Hi Norbert,
> >
> > make sure your /usr/local mount is done in the initrd and that you
use
> > »systemctl link /path/to/unit.service« to enable them.
> That's not really helping, I don't want to chug in tons of tools in
> the initramfs this is no desktop system.
> systemctl link shouldnt be necessary, as
/usr/local/lib/systemd/system
> is a standard unit path.

You're right with the path, I re-checked it.
For your initrd the general suggestion is to actually include systemd
in it. See https://systemd.io/INITRD_INTERFACE/ for everything.
>
> Since there is a systemd-update-done that changes /etc I would have
thought that
> systemd rereads the configuration (as /etc/systemd/system could have
> changed) during startup.
> I would want that for /usr/local/lib/systemd/system after this path
> was made available through a mount.
>
> If systemd assumes the whole /usr drive to be static and has no way
to
> dynamically reload and "retarget"
> (adding new wants/requires dependencies to starting/started targets)
> then I guess that's the end of it.
>
> I dont know if thats the case or if I just dont know how (as
> systemd-update-done allows a changing /etc I would assume systemd
> would rescan it for units/dependencies)

systemds internal unit representation is actually static. Unit files
are only read when started as PID1 after the generators ran, while
switch-root'ing from the initrd and everytime you run »systemctl
daemon-re{load,exec}« (there are transient units as well, but this
would be to much for here).

What you could try is creating a new unit in /etc/systemd/system/
--- systemd-reload.service ---
[Unit]
Description=Reload systemd
Requires=usr-local.mount
After=usr-local.mount

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl --no-block daemon-reload

[Install]
WantedBy=usr-local.mount
---
and than a »systemctl daemon-reload && systemctl enable systemd-
reload.service«.
In theory (because completly untested) this unit should be activated as
soon as your /usr/local mount point is ready.
>
> >
> > For the automount behaviour, you need to add
> > »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s«
> > to the options part in the /etc/fstab. See man:systemd.mount for
more
> > information.
>
> Thats Automount, but I want "LazyUnmount",
> and the suggestion kinda contradicts "make sure your /usr/local mount
> is done in the initrd"

The »x-systemd.idle-timeout=10s« actually unmounts the disk as soon as
10s long the disk is idle. Idle is defined as
- open file descriptors and
- process working directory.
So LazyUnmount (which you can define in an actual .mount unit) wouldn't
change anything IMHO.

(sorry for sending twice. Forgot the ML)


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Reloading configuration after mount unit

[Silvio Knizek]

Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange:
> Hello,
>
> I have an extra mount for /usr/local (Tools + Services which are just
> useful for development), classically done vie /etc/fstab.
>
> Now there are a few systemd services within /usr/local/lib and systemd
> does not seem to load/reload those and start the ones that add a
> sysinit.wants.
>
> currently I have to do the following to get a "full start":
> systemctl daemon-reload
> systemctl start default.target
>
> What would be the correct way to cause systemd to reevaluate configuration?
> I get that this generally could lead to bad behaviour (endless
> reconfiguration if cycles),
> but for something hierarchical like mount-paths it should be possible.
>
> I could think of a unit having an after/requires to usr-local.mount or
> using a path unit watching PathChanged=/usr/local/lib/systemd.
> At any rate, I am not sure how I could tell systemd to start new units
> wanted by eg.
> sysinit.target if this was already fully started. `systemctl start
> default.target` seems
> a bit dangerous.
>
> Another, less important issue is that I cant set lazy unmount in fstab.
>
> Norbert.
Hi Norbert,

make sure your /usr/local mount is done in the initrd and that you use
»systemctl link /path/to/unit.service« to enable them.

For the automount behaviour, you need to add
»noauto,x-systemd.autmount,x-systemd.idle-timeout=10s«
to the options part in the /etc/fstab. See man:systemd.mount for more
information.

HTH
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sibling DNS lookup of nspawn containers

[Silvio Knizek]

Am Donnerstag, dem 17.06.2021 um 20:26 -0700 schrieb Johannes Ernst:
> I’d like to be able to DNS lookup container b from within container a, if 
> both were started with systemd-nspawn as siblings of each other, and shown as 
> a and b in machinectl list.
>
> man nss-mymachines specifically notes it won’t do that.
>
> What’s the proper way of doing this?
>
> Thanks,
Hi Johannes,

you would enable LinkLocalMulticastNameResolution (LLMNR) in the
containers systemd-networkd.
See man:networkd.conf for further information.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] bamboo agent does not start from systemd

[Silvio Knizek]

Am Mittwoch, dem 16.06.2021 um 10:00 -0400 schrieb vad...@gmail.com:
> Bamboo agent install provides bamboo-agent.sh as part of the install.
> It starts the bamboo agent. It works fine provided there is no service
> unit file defined. If I define the service unit file it does not start
> with systemctl. It also fails to start even when executing
> bamboo-agent.sh start as bamboo. This seems very odd. Here are some
> details.
>
> # cat /etc/systemd/system/bamboo-agent.service
> [Unit]
> Description=Atlassian Bamboo Agent
> After=syslog.target network.target
> [Service]
> Type=forking
> User=bamboo
> Group=bamboo
> ExecStart=/bin/bash /opt/atlassian/remote-agent/bin/bamboo-agent.sh start
> ExecStop=/bin/bash /opt/atlassian/remote-agent/bin/bamboo-agent.sh stop
> [Install]
> WantedBy=multi-user.target
>
> [root@bamboo remote-agent]# systemctl start bamboo-agent
> Job for bamboo-agent.service failed because the control process exited
> with error code. See "systemctl status bamboo-agent.service" and
> "journalctl -xe" for details.
>
> [root@bamboo remote-agent]# systemctl status -l bamboo-agent
> ● bamboo-agent.service - Atlassian Bamboo Agent
> Loaded: loaded (/etc/systemd/system/bamboo-agent.service; disabled;
> vendor preset: disabled)
> Active: failed (Result: exit-code) since Tue 2021-06-15 18:59:58 UTC; 12s ago
> Process: 5680 ExecStart=/bin/bash
> /opt/atlassian/remote-agent/bin/bamboo-agent.sh start (code=exited,
> status=1/FAILURE)
> Jun 15 18:59:57 bamboo.example.org systemd[1]: Starting Atlassian
> Bamboo Agent...
> Jun 15 18:59:57 bamboo.example.org bash[5680]: Starting Bamboo Agent
> with systemd...
> Jun 15 18:59:58 bamboo.example.org bash[5680]: Failed to start
> bamboo-agent.service: Interactive authentication required.
> Jun 15 18:59:58 bamboo.example.org bash[5680]: See system logs and
> 'systemctl status bamboo-agent.service' for details.
> Jun 15 18:59:58 bamboo.example.org systemd[1]: bamboo-agent.service:
> control process exited, code=exited status=1
> Jun 15 18:59:58 bamboo.example.org systemd[1]: Failed to start
> Atlassian Bamboo Agent.
> Jun 15 18:59:58 bamboo.example.org systemd[1]: Unit
> bamboo-agent.service entered failed state.
> Jun 15 18:59:58 bamboo.example.org systemd[1]: bamboo-agent.service failed.
>
> As you can see I cannot start manually either when the service unit exist
>
> [root@bamboo remote-agent]# su - bamboo
> [bamboo@bamboo ~]$ /opt/atlassian/remote-agent/bin/bamboo-agent.sh start
> Starting Bamboo Agent with systemd...
>  AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
> Authentication is required to manage system services or units.
> Authenticating as: Cloud User (ec2-user)
> Password:
>
> If I remove the service unit I can manually start.
>
> [root@bamboo remote-agent]# mv /etc/systemd/system/bamboo-agent.service /tmp
> [root@bamboo remote-agent]# systemctl daemon-reload
> [root@bamboo remote-agent]# su - bamboo
> [bamboo@bamboo ~]$ /opt/atlassian/remote-agent/bin/bamboo-agent.sh start
> Starting Bamboo Agent...
> Waiting for Bamboo
> Agent...
> running: PID:6449
> [bamboo@bamboo ~]$
>
> It seems to me the bamboo-agent.sh that comes with installation has
> bug in it. I am attaching bamboo-agent.sh file here as well.
>
> Any suggestion how to get it running from systemd?
>
> Thanks,
> Asif
Hi Asif,

the wrapper script tries to do what systemd already does. Trash it and
write your own .service. Especially the »su« in such scripts breaks
things, because it creates its own login session via PAM.

Check all the wrapper scripts called and how they interact, so you
actually get to the plain java call.

The file you attached actually has systemd support. Try
»/opt/atlassian/remote-agent/bin/bamboo-agent.sh install«

HTH
Silvio



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Block systemd from adding new services

[Silvio Knizek]

Am Sonntag, dem 13.06.2021 um 10:49 -0400 schrieb Saint Michael:
> This is not a human attacker, but a robot. My question is: if I apply
> chattr +i to $(pkg-config --variable=systemdsystemconfdir systemd),
> will the OS continue to work fine or this is nonsense?
> Philip
Systemd will work totally fine (except »systemctl edit« probably). But
the point stays: if your attacker has root rights, nothing prevents
them for setting »chattr -i« on the confdir. So IMHO your approach is
futile.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Block systemd from adding new services

[Silvio Knizek]

Am Sonntag, dem 13.06.2021 um 09:32 -0400 schrieb Saint Michael:
> One of the most dramatic hacks to 50+ servers of mine is a bitcoin
> miner, xmrig. It installs a service file at /etc/systemd/system,
> enables it and kills the machine. 
> Nobody knows how it propagates. I think that SSHD has been broken in
> a foreign land or they just brute-force any machine where
> passwordautorization=yes. 
> The point is, for this list, how can I prevent systemd from adding
> ANY new service at all. I am thinking to add chattr +i to
> /etc/systemd/system, but want to know if this makes any sense or if
> there is a better way to do this.
> Philip
Hi Philip,

if someone can add files into
$(pkg-config --variable=systemdsystemconfdir systemd)
then the attacker has already root rights, so any suggestion here would
only be a nuisance for an attacker. Be happy that the payload wasn't
written in the boot loader.

A general approach would be a stateless system with man:systemd.preset
and a /etc as tmpfs, so after a reboot the system would be fresh again.
Disabling root login via ssh is always a good idea and only using
polkit/sudo for elevating rights. This could be combined with some two-
factor authentication via PAM, so a cracked/guessed password isn't the
end.

But in the end this are all generic approaches to system security,
nothing systemd specific.

HTH
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rg...@outlook.com

[Silvio Knizek]

Am Montag, dem 07.06.2021 um 21:26 +0530 schrieb Aravindhan Krishnan:
> Hi Folks,
>
> I am finding anomalous behavior when I am trying to run dhclient
> process inside my docker container in vanilla Ubuntu 16.04 host. The
> service gets into "deactivating" state and is stuck forever. In the
> mail I have attached a minimalistic reproduction of the issue seen.
> Thanks,
> Aravindhan
>
> Regards,
> Aravindhan Krishnan...
Hi Aravindhan,

don't run systemd in a docker container in the first place? Also Ubuntu
16.04 is really old.
IMHO all your problems are created by your setup itself. I really
appreciate the minimal example you attached, but if your premise
(running systemd in a docker container and not just one simple process)
is already wrong, than no solution can be right.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to prevent systemd-logind from moving process to other cgroups when executing su command

[Silvio Knizek]

Am Dienstag, dem 25.05.2021 um 22:23 +0800 schrieb 吾为男子:
> Systemd provides pam_systemd.so for PAM module and for many commands,
> such as su command, pam_systemd.so will be called and the process
> will be moved to the cgroup that systemd managed.
Regardless your problem, `su` is never the solution.
What actual problem do you want to solve? Have you checked out
`systemd-run`? Do you want to run some `init` scripts from $vendor
stuck in 2002?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] permanent autologin

[Silvio Knizek]

Am Sonntag, dem 02.05.2021 um 19:14 +0200 schrieb Emanuel Berg:
> Silvio Knizek wrote:
>
> >
> > your path is wrong. You want the following:
> >
> > /etc/systemd/system/getty@tty1.service.d/10-autologin.conf
>
> I don't have that file or even directory, but I can put it
> there manually, of course.
It's expected that you don't have this directories and files. You can
just create them. In man:systemd.unit you find how templates and drop-
ins work.
After touching those files you need to run »systemd deamon-reload« to
tell systemd, that you touched them.
>
> > Do you need this auto login for debug reasons (than maybe
> > debug- shell.service is better suited), do you want to start
> > a terminal 1application (than maybe use a normal .service
> > with TTYPath), or do you start graphical applications (use
> > a login manager with auto login instead)?
>
> I have it setupt like this [1] so that
>
> Linux VT   1 -> Emacs
>  2-4 -> tmux
>    5 -> (do nothing)
>    6 -> X
>
> I don't really "need" auto login, it is more like I want it :)
>
> [1] https://dataswamp.org/~incal/conf/.zprofile
>
So, if you have this setup, I really suggest that you use specialised
units for every terminal and a graphical login manager for the X stuff.
So instead of starting agetty you can directly start emacs or tmux as
the User= you want.
And again for X, you want a graphical login manager, beacuse than your
session has proper access rights and is in fact tagged as graphical by
loginctl.
Or you drop the ttys completely and work only in X, like everybody else
and use some window manager with multiple desktops.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] permanent autologin

[Silvio Knizek]

Am Samstag, dem 01.05.2021 um 07:17 +0200 schrieb Emanuel Berg:
> I do autologin like this:
>
>    ExecStart=-/sbin/agetty -a incal --noclear %I $TERM
>
>    /etc/systemd/system/getty.target.wants/getty@tty1.service # line ~39
>
>    $ sudo systemctl daemon-reload
>
> However, it seems to disappear after a while, maybe when
> systemd gets updated?
>
> So my question is how do I make the autologin
> change permanent?
>
Hi Emanuel,

your path is wrong. You want the following:

--- /etc/systemd/system/getty@tty1.service.d/10-autologin.conf
[Service]
ExecStart=
ExecStart=-/sbin/agetty -a incal --noclear %I $TERM
---

This creates a single overwrite for only this one instanciated unit.
The first empty ExecStart= is for technical reasons.

Do you need this auto login for debug reasons (than maybe debug-
shell.service is better suited), do you want to start a terminal
1application (than maybe use a normal .service with TTYPath), or do you
start graphical applications (use a login manager with auto login
instead)?

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Silvio Knizek]

Am Freitag, dem 30.04.2021 um 10:39 -0400 schrieb Rick Winscot:
> My question for anyone on the list, is the method outlined below a
> reasonable solution to mounting /var early in the start-up cycle?
>
> Or... is there a better way? Some trimming
>

Hi Rick,

by definition if you need to mount /var (or /usr for this argument),
you need an initrd [1] which actually set up everything as you
requires. Anything else has a tendency to break in unpleasant ways due
to race conditions and such. You don't need much, just enough to set up
everything required for the root and API file systems.

BR
Silvio

[1] https://systemd.io/INITRD_INTERFACE/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "Correct" way to obtain DHCP lease info?

[Silvio Knizek]

Am Mittwoch, dem 21.04.2021 um 14:24 -0400 schrieb Bruce A. Johnson:
> Is there a correct way to obtain information about the DHCP lease 
> received by systemd-networkd's DHCP client functionality? It was easy 
> enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but 
> there is a big fat warning stamped at the top of the file:
> 
> > # This is private data. Do not parse.
> I'd like to be able to make a widget that can tell me which DHCP server 
> issued my lease, how much more time I have, etc., mainly because I want 
> to be able to ping something that is known to be on the network. I'm 
> dealing with a lazy sysadmin who doesn't want to put a gateway on this 
> private network, I haven't found a solution using the CLI tools.
> 
> Thanks in advance.
Hi Bruce,

IMHO "having a lease" is not a good metric to determine if you can
access something.
I would suggest something along this line:

--- /etc/systemd/system/internal-network-accessable.target
[Unit]
Description=Internal System Accessable
---
--- /etc/systemd/system/check-if-internal-system-is-accessable.service
[Unit]
Description=Check if internal system can be reached

[Service]
ExecStart=/usr/local/bin/check-if-internal-system-is-accessable.sh
Restart=always

[Install]
WantedBy=multi-user.target
---
--- /usr/local/bin/check-if-internal-system-is-accessable.sh
#!/usr/bin/bash
while :; do
if wget -q --spider $INTERNAL_RESOURCE; then
systemctl start internal-network-accessable.target
else
systemctl stop internal-network-accessable.target
fi
sleep 600
done
---

Than you can check just the status of the .target. You may need to
tweak the lifeness probe, YMMV.

Also in sd-networkd you can configure a .network to never loose its
lease, see man:systemd.network → KeepConfiguration=

HTH
Silvio


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .local searches not working

[Silvio Knizek]

Am Freitag, dem 09.04.2021 um 14:27 -0400 schrieb Phillip Susi:
> What special treatment does systemd-resolved give to .local domains?
> The corporate windows network uses a .local domain and even when I
point
> systemd-resolved at the domain controller, it fails the query without
> bothering to ask the dc saying:
>
> resolve call failed: No appropriate name servers or networks for name
> found
Well, .local is by definition special as it is reserverd for
MulticastDNS [1].
The man page [2] itself says

> Multi-label names with the domain suffix ".local" are resolved using
> MulticastDNS on all local interfaces where MulticastDNS is enabled.
> As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6
> address lookups are sent via IPv6.
>
> Queries for multi-label names are routed via unicast DNS on local
> interfaces that have a DNS server configured, plus the globally
> configured DNS servers if there are any. Which interfaces are used
> is determined by the routing logic based on search and route-only
> domains, described below. Note that by default, lookups for domains
> with the ".local" suffix are not routed to DNS servers, unless the
> domain is specified explicitly as routing or search domain for the
> DNS server and interface. This means that on networks where the
> ".local" domain is defined in a site-specific DNS server, explicit
> search or routing domains need to be configured to make lookups work
> within this DNS domain. Note that these days, it's generally
> recommended to avoid defining ".local" in a DNS server, as RFC6762
> reserves this domain for exclusive MulticastDNS use.

So in fact your network is not standard conform. You have to define
.local as search and routing domain in the configuration of sd-
resolved.

BR
Silvio

[1] https://tools.ietf.org/html/rfc6762#section-3
[2]
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hostnamectl set-hostname non-admin user

[Silvio Knizek]

Am Dienstag, dem 06.04.2021 um 16:21 +0300 schrieb Damien LEFEVRE:
> Hi,
>
> I have an embedded device and I do not install sudo. I need to have a
> non-root running the main service capable of changing the hostname.
>
> After spending a long afternoon on this I still have not managed.
>
> Here i've tried adding my new user but only read-only requests go
> through
> /usr/share/dbus-1/system.d/org.freedesktop.hostname1.conf
> ```xml
>  
>  Configuration 1.0//EN"
>        
> "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>
>
> 
>
> 
>
>     
>         
>         
>         
>     
>
>     
>         
>         
>         
>     
>
>     
>         
>         
>     
>
> 
> ```
>
>
> /usr/share/polkit-1/actions/org.freedesktop.hostname1.policy
> ```xml
>  
>  Configuration 1.0//EN"
>         "
> http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd;>
>
> 
>
> 
>
>         The systemd Project
>        
> http://www.freedesktop.org/wiki/Software/systemd url>
>
>         
>                 Set host
> name
>                 Authentication is
> required to set the local host name.
>                 
>                         auth_admin_keep
>                        
> auth_admin_keep
>                         auth_admin_keep
>                 
>         
>
>         
>                 Set static host
> name
>                 Authentication is
> required to set the statically configured local host name, as well as
> the pretty host name.
>                 
>                         auth_admin_keep
>                        
> auth_admin_keep
>                         auth_admin_keep
>                 
>                  key="org.freedesktop.policykit.imply">org.freedesktop.hostname1.set-
> hostname org.freedesktop.hostname1.set-machine-info
>         
>
>         
>                 Set machine
> information
>                 Authentication is
> required to set local machine information.
>                 
>                         auth_admin_keep
>                        
> auth_admin_keep
>                         auth_admin_keep
>                 
>         
>
>         
>                 Get product
> UUID
>                 Authentication is
> required to get product UUID.
>                 
>                         auth_admin_keep
>                        
> auth_admin_keep
>                         auth_admin_keep
>                 
>         
>
> 
> ```
>
> Despite all my attempts I always get 'Could not set property: Access
> denied' for hostnamectl set-hostname
>
> And get the 'org.freedesktop.DBus.Error.AccessDenied' in dbus-monitor
>
> method call time=1617739342.317948 sender=:1.23 ->
> destination=org.freedesktop.hostname1 serial=3
> path=/org/freedesktop/hostname1; interface=org.freedesktop.hostname1;
> member=SetStaticHostname
>    string "blabla"
>    boolean true
> ...
> error time=1617739342.320289 sender=:1.24 -> destination=:1.23
> error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=3
>    string "Permission denied"
>
>
> Any help would be greatly appreciated =)
>
> -Damien

Hi Damien,

you actually need to configure polkit for this. Something like
/etc/polkit-1/rules.d/49-allow-myuser-access-to-hostnamed.rules

```javascript
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.hostname1.set-hostname") {
if (subject.user == "myuser") {
return polkit.Result.YES;
}
}
});
```

Your dbus definition only says that one can define rules including such
actions.

HTH
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Guidance on automount/unmount for external powered devices

[Silvio Knizek]

Am Donnerstag, dem 11.03.2021 um 11:00 + schrieb Patrick
O'Callaghan:
> Apologies in advance if this is a FAQ, or if there is a more
> appropriate list for this question. I'm looking for a step-by-step
> guide for the following situation:
>
> I have an external 2-bay USB3 drive enclosure, configured as an MD
> Raid-1 device. This works without issue.
>
> I normally only use the device for nightly backups, so would prefer to
> leave it powered off until needed.
>
> I have scripts to power it up (creating the appropriate /dev/md entry
> and mounting the drive) and down (unmounting, removing the /dev/md
> entry and sending a magic signal to the USB device so it powers itself
> down after 30 minutes).
>
> Unfortunately a system reboot always leaves it in the 'powered up and
> present in /dev/md' state, so I have to manually run the power-down
> script every time I reboot. This is inelegant.
>
> I would much prefer to have this all handled automagically by systemd,
> but I need guidance on how to configure it. If it weren't for the power
> question, I know I can just use automount (and have managed to get this
> far on my own), but I don't know where or how to insert the power
> scripts. My reading of the systemd docs leads me to think that
> ExecStart/Stop might be the way, but where do I put this? Do I need a
> specific foo.mount unit (I'm currently using /etc/fstab)?
>
> poc
Hi,

I don't really understand your problem. Do you want to unmount the
backup drive whenever it's not in use? There is the mount option x-
systemd.automount,x-systemd.idle-timeout=5s (man systemd.mount) to
mount/unmount on demand.

Can you share your fstab entry for your backup device?

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q on serial-getty

[Silvio Knizek]

Am Mittwoch, den 07.10.2020, 08:49 +0200 schrieb Ulrich Windl:
> Hi!
>
> I'm thinking of configuring a serial getty in SLES15 (systemd-234). First I 
> found that there is no manual page describing the service, and second if I 
> use "systemctl show serial-getty" ("systemctl show serial-getty@" does not 
> work), I get some "funny" numbers:
>
> ...
> UID=4294967295
> GID=4294967295
> ...
> MemoryCurrent=18446744073709551615
> CPUUsageNSec=18446744073709551615
> TasksCurrent=18446744073709551615
> IPIngressBytes=18446744073709551615
> IPIngressPackets=18446744073709551615
> IPEgressBytes=18446744073709551615
> IPEgressPackets=18446744073709551615
> ...
> CPUWeight=18446744073709551615
> StartupCPUWeight=18446744073709551615
> CPUShares=18446744073709551615
> StartupCPUShares=18446744073709551615
> ...
>
> Obviously that number is the unsigned 64-bit representation of -1, but 
> considering that no such service is running, the output looks quite odd.
> If -1 means "unknown", why not use that string, or if it means "unlimited", 
> why not use that string?
>
> Regards,
> Ulrich

Hi Ulrich,

have you already tried `systemctl help serial-getty@foo.service` (yes,
instanciatable units need a instance token, even if useless)? This
should open some documentation.
Also, for the serial getty actually a generator is used to
automatically start it, if already requested by the boot loader and
kernel command line. See man:systemd-getty-generator(8) and
http://0pointer.de/blog/projects/serial-console.html for more
information.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: systemctl kill: "Invalid who argument 15862"

[Silvio Knizek]

Am Mittwoch, den 06.05.2020, 11:21 +0200 schrieb Ulrich Windl:
> Hi!
>
> I have a question for systemd-228-150.82.1.x86_64 (of SLES12 SP4):
> While developing a script for logrotate, I tested this command with the
> following result:
>
> # systemctl kill -s HUP --kill-who=15862 iotwatch@LOC1.service
> Failed to kill unit iotwatch@LOC1.service: Invalid who argument 15862
>
> That's odd, because:
> # systemctl status iotwatch@LOC1
> ● iotwatch@LOC1.service - iotwatch I/O performance monitor instance "LOC1"
>Loaded: loaded (/etc/iotwatch.conf; enabled; vendor preset: disabled)
>Active: active (running) since Tue 2020-03-10 07:58:35 CET; 1 months 26
> days ago
>  Docs: man:iotwatch(1)
>man:iotwatch@.service(8)
>  Main PID: 15862 (iotwatch-LOC1)
> Tasks: 4 (limit: 512)
>CGroup: /system.slice/system-iotwatch.slice/iotwatch@LOC1.service
>└─15862 iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log
> ...
>
> Mar 10 07:58:35 rksapv04 systemd[1]: Starting iotwatch I/O performance
> moni.
> Mar 10 07:58:35 rksapv04 systemd[1]: Started iotwatch I/O performance
> monit...".
> Hint: Some lines were ellipsized, use -l to show in full.
>
>
> Did I misinterpret the manual page, or what is the problem?
>
>--kill-who=
>When used with kill, choose which processes to send a signal to.
>Must be one of main, control or all to select whether to kill only
>the main process, the control process or all processes of the
> unit.
>
> Regards,
> Ulrich

Hi Ulrich,

as you quoted right --kill-who takes either "main", "control" or "all",
not a PID.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-level]: how to change default timezone in systemd code?

[Silvio Knizek]

Am Mittwoch, den 29.04.2020, 20:31 +0800 schrieb www:
> Dear All,
>
> I want to change the default timezone in systemd, when it first starts, it 
> shows the time zone I want. How can I modify the code in systemd to implement 
> the function?
>
> thanks,
> Byron
Hi,

the default timezone is just the symlink /etc/localtime to
../usr/share/zoneinfo/your/timezone
There is no magic behind this. It can be easy automated and pre-
configured.
You can use systemd-firstboot to set the timezone, too.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd autofs in RH 7

[Silvio Knizek]

Am Dienstag, den 21.04.2020, 14:33 + schrieb Wieschke, Thomas:
> Hi,
> thanks fort he quick response. After having a first look at the man pages, I 
> mentioned that I would have a choice between
> a fstab based solution or a unit file based one, right?
> Because I have a mix of ~ 10 different Mounts (CIFS, NFS) /workdir/in, 
> /workdir/out, /workdir/bla, /workdir/send ...
> I have a tendency to fstab because it seems better manageable or what would 
> you suggest?
>
> BR
> Thomas
Hi Thomas,

using the fstab is the preferred interface.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd autofs in RH 7

[Silvio Knizek]

Am Dienstag, den 21.04.2020, 13:26 + schrieb Wieschke, Thomas:
> Hi,
> I hope someone can help with the following case.
>
> I'm writing on a RH 7 system to an automounted FS and get an disruption 
> because systemd (??) is,
> besides working in this directory, obviously trying an umount in the 
> background.
> The umount doesn't work because the FS is in use (returned busy), but the 
> start/stop of autofs is
> nevertheless done and leads to a disruption:
>
> Apr 21 12:02:18 server1 systemd[1]: Stopping Automounts filesystems on 
> demand...
> -- Subject: Unit autofs.service has begun shutting down
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit autofs.service has begun shutting down.
> Apr 21 12:02:19 server1 automount[22213]: umount_autofs_indirect: ask umount 
> returned busy /vsaabrmount
> Apr 21 12:02:20 server1 systemd[1]: Stopped Automounts filesystems on demand.
> -- Subject: Unit autofs.service has finished shutting down
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit autofs.service has finished shutting down.
> Apr 21 12:02:20 server1 systemd[1]: Starting Automounts filesystems on 
> demand...
> -- Subject: Unit autofs.service has begun start-up
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit autofs.service has begun starting up.
> Apr 21 12:02:20 server1 systemd[1]: Started Automounts filesystems on demand.
> -- Subject: Unit autofs.service has finished start-up
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit autofs.service has finished starting up.
> --
> -- The start-up result is done.
>
> Finally I tried to prevent any umount by changing in /etc/sysconfig/autofs 
> #OPTIONS="" to OPTIONS="-timeout=0"
>
> And I tried to add in /etc/auto.master at end of line --timeout=0 (/workdir   
>  /etc/auto.workdir --timeout=0)
>
> But besides this values there is an automatic restart every 30min
>
> Apr 21 13:34:41 server1 systemd: Stopping Automounts filesystems on demand...
> Apr 21 13:34:42 server1 systemd: Starting Automounts filesystems on demand...
> Apr 21 13:34:42 server1 systemd: Started Automounts filesystems on demand.
> Apr 21 14:04:42 server1 systemd: Stopping Automounts filesystems on demand...
> Apr 21 14:04:42 server1 systemd: Stopped Automounts filesystems on demand.
> Apr 21 14:04:42 server1 systemd: Starting Automounts filesystems on demand...
> Apr 21 14:04:42 server1 systemd: Started Automounts filesystems on demand.
> Apr 21 14:34:42 server1 systemd: Stopping Automounts filesystems on demand...
> Apr 21 14:34:42 server1 automount[11019]: umount_autofs_indirect: ask umount 
> returned busy /vsaabrmount
> Apr 21 14:34:44 server1 systemd: Stopped Automounts filesystems on demand.
> Apr 21 14:34:44 server1 systemd: Starting Automounts filesystems on demand...
> Apr 21 14:34:44 server1 systemd: Started Automounts filesystems on demand.
>
> Switching back to RH 6 doesn't show this problem.
>
> Any suggestions?
>
> Thanks in advance
>
> Best regards
> Thomas

Hi Thomas,

don't use autofs, but systemd.automount for this. It does exactly what
you want, but in the context of systemd. See man:systemd.automount for
more information.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stateless system - Centos8 and overlayfs on root

[Silvio Knizek]

Am Freitag, den 27.03.2020, 10:17 -0700 schrieb Preston L. Bannister:
> Looking for a sanity check from the folk how know more of systemd than do I. 
> Not looking for someone else to solve my problem, but could use a clue.
>
> Trying to figure out how to get an overlayfs root mounted early in boot.
>
> Building an embedded system that must not store any sensitive data when 
> powered down. Found this was referred to on this list more recently as a 
> "stateless" system. (And Tobias Hunger seems to have the most to say. :) ) We 
> are using Centos8, with systemd 239. Starting point is a vanilla Centos8 
> server installation to a small (8 or 32GB) flash volume.
>
> Had the (possibly) clever notion of using an overlayfs as the root mount, 
> with a tmpfs as the upper, and the usual persistent volume as the lower. The  
> initial round of configuration and test would just be against a stock Centos8 
> install. Once fully configured and tested, would add a default boot menu item 
> to boot with root mounted as an overlayfs, with the fully configured root 
> volume as the read-only lower.
>
> Updates would be accomplished by booting from the original boot menu entry. 
> (This is slightly complicated by the fact the target systems' computers do 
> not have a console - but figure I can script altering the default boot.)
>
> Have what I think is a properly configured overlayfs root. Currently hung up 
> on getting that root mounted early enough(?) in boot. Working down a list of 
> possibilities. :)
>
> Have a script to repeatably build/rebuild the overlayfs root. Relevant 
> commands (w/o supporting logic):
> 
> BASE=/run/overlay_root
> OVERLAY=$BASE/merged
> ROOT_MOUNT=$OVERLAY/mnt/root
> mount -t tmpfs root-base $BASE ; mkdir $BASE/{lower,upper,work,merged}
> mount --bind / $BASE/lower
> mount -t overlayfs root-overlay $OVERLAY 
> -olowerdir=$BASE/lower,upperdir=$BASE/upper,workdir=$BASE/work
> for d in boot dev proc run sys ; do mount --bind /$d $OVERLAY/$d ; done
> mkdir $ROOT_MOUNT ; mount --bind / $ROOT_MOUNT
> 
> This all seems to work. The overlayfs prevents writes to persistent media in 
> usual places. Have a path to write to persistent media. The special 
> directories (that do not work from mounts to lower on an overlayfs) work as 
> expected.
>
> What I do not have as yet is a means to get the overlayfs root mounted early 
> in boot.
> 1.  Does not look like /etc/fstab can create the overlayfs.
> 2.  Tried the "systemd.volatile=yes" kernel command line, w/o luck. 
> Substantial commits between 239 and 245 around this.
> 3.  See systemd "pivot_root" and "switch_root", but not yet puzzled out usage.
>
> Looking for where/how to swap in the overlayfs root early in boot. Or tell me 
> I'm an idiot, and this will not work. :/

Hi Preston,

So, you need a initramfs doing this for you and where you do all the
mounting. Or you use tmpfiles.d snippets and /etc as tmpfs. See
http://0pointer.net/blog/projects/stateless.html for more information.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mutually exclusive (timer-triggered) services

[Silvio Knizek]

Am Montag, den 14.10.2019, 18:30 +0200 schrieb Alexander Koch:
> > exactly for this you would use a flock(1) in your .service.
>
> Thanks for the hint, didn't have that in mind. So you're suggesting
> something like this?
>
>  # service-a.service
>  # (...)
>  [Service]
>  ExecStart=/usr/bin/flock -F /var/lock/resource.lock
> /usr/bin/service-a
>
>  # service-b.service
>  # (...)
>  [Service]
>  ExecStart=/usr/bin/flock -F /var/lock/resource.lock
> /usr/bin/service-b
>
>
> I see some drawbacks of this approach:
>
> * Wrapping the actual command in an flock call seems pretty ugly in
> my eyes, i.e. looking at the `ExecStart=` lines above I find it very
> hard to see where the former begins, at first glance. This is
> subjective, of course.
You could use something like

ExecStart=/usr/bin/flock -F /path/to/lock.file \
  /your/actual/command --with argument

Should be easier on the eyes.
>
> * flock leaves the lock file behind so you'd need some type of
> cleanup in case you really want the jobs to be trace-free. This is
> not as trivial is it might seem, e.g. you cannot do it from the
> service units themselves in `ExecStartPost=` or similar.
An

ExecStartPost=-/usr/bin/flock -F /path/to/lock.file \
  /usr/bin/rm /path/to/lock.file

should solve this issue.
>
> * /var/lock is very likely not user-writable so you'd need a
> different lock file directory for user services. You could of course
> use /tmp for that.
For this I would suggest StateDirectory=. See man:systemd.exec for more
information
>
> * File-based locking makes it impossible to use private filesystem
> namespaces for the service units (think of `PrivateTmp=yes` and lock
> files in /tmp).
If a StateDirectory= is used than only the access rights are important.
>
>
> As systemd (or service managers in general) are all about queueing,
> ordering and controlling services and their dependencies I had hoped
> there would be a cleaner solution using systemd internals rather than
> solving it using external tools, which mixes up the service call
> itself with its requirements (exclusive resource access).
>
> Nevertheless I think I will go with your proposal and see how it
> works out.
If your units are actually dependent on each other, than maybe you
should think about your approach in general. But to be able to help you
with that we need more information about the actual dependencies of the
applications started by your units and at which interval they shall
run.
>
>
> Best regards,
>
> Alex
BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mutually exclusive (timer-triggered) services

[Silvio Knizek]

Am Montag, den 14.10.2019, 12:45 +0200 schrieb Alexander Koch:
> Dear [systemd-devel],
>
> imagine you've got multiple services that perform system housekeeping
> tasks, all triggered by .timer units. These services all happen to
> use
> a specific resource (e.g. the system package manager) so they must
> not
> be run in parallel, but they all need to be run.
>
> Is there a systemd'ish way of modeling this?
>
> I first thought of using `Conflicts=` but having read the manpages I
> understand that queueing one of the services would actively stop any
> running instance of any of the others.
>
> `After=` is not an option either as that (unless 'Type=oneshot',
> which
> isn't to be used for long-running tasks) doesn't delay up to
> completion
> but only to initialization. Furthermore I think you'd run into
> trouble
> ordering more than two units using this approach.
>
> Ideally I'd think of something like a 'virtual resource' that can be
> specified by service units, like this (real use case on Arch Linux):
>
>  [Unit]
>  Description=Pacman sync
>  Locks=pacman-db
>
>  [Service]
>  ExecStart=/usr/bin/pacman -Sy
>
>  
>
>  [Unit]
>  Description=Pacman cleanup
>  Locks=pacman-db
>
>  [Service]
>  ExecStart=/usr/bin/paccache -r -k 0 -u
>
> The value of `Locks=` shall be an arbitrary string describing the
> virtual resource the service is requiring exclusive access to.
> systemd
> would then delay the start of a unit if there is another unit with
> identical `Locks=` entry currently active.
>
> A nice advantage of this concept is that services depending on the
> same
> virtual resource would not need to know of each other, which
> simplifies
> shipping them via separate packages.
>
> Any thoughts on this? Maybe I'm just too blind to see the obvious
> solution to this simple problem.
>
>
> Best regards,
>
> Alex
Hi Alex,

exactly for this you would use a flock(1) in your .service.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Deferring start of service until file exists

[Silvio Knizek]

Am Mittwoch, den 21.08.2019, 09:32 +0100 schrieb Colin Hogben:
> On 20/08/19 16:54, Silvio Knizek wrote:
>
> > The NFS root needs to be mounted in the initrd step. Else
> > everything will break. With systemd in the initrd you gain the
> > possibilty to depend on those units in the actual system.
>
> Booting with an NFS root is working fine.  I'm not sure how to tell
> whether or not I have "systemd in the initrd" as you describe; I
> built the initrd with dracut, and I get the
>random: systemd-udevd: uninitialized urandom read (16 bytes read)
> messages before
>dracut: Mounted root filesystem ...
Ah, than it should be fine. dracut actually does it right®
>
> > Why not systemd-networkd,
>
> systemd-networkd is inadequate for the task.  Even though I could
> potentially parse the ntp servers out of the lease file (is that even
> a public interface with stable format?), I didn't find a way,
> documented or undocumented, for getting the log-server.  Indeed, from
> scanning the source code it seems that any DHCP options other than
> some core ones and those in the private range, e.g. 7 (log-server),
> are just ignored. (Bizarrely, systemd-networkd does include a DHCP
> server - WTF?! DOTADIW?  But I digress...)
sd-networkd would tell sd-timesyncd by themself. But yeah, currently
you can't add random options to the dhcp client.
>
> > systemd-journald with remote-forwarding
> > enabled
>
> I didn't know it could do that.  Googling e.g.
> https://unix.stackexchange.com/questions/394822 and the linked
> Redhat recommendation suggest otherwise.  I found references to
> systemd-journal-netlogd (WIP? PR #1890 rejected), and some other
> systemd stuff which didn't support traditional UDP output.
sd-journald would use it's own transport via HTTP(S). See man:systemd-
journal-gatewayd, man:systemd-journal-upload and man:systemd-journal-
remote
There are also other tools to directly read from the journal and into
the appropriate backend for elasticsearch, graylog and other.
>
> > and systemd-timesyncd?
>
> Only because it isn't (wasn't) packaged for CentOS 7.  In fact I used
> it  in another project and I'd forgotten I even found a way to
> integrate it with dhclient:
> https://www.raspberrypi.org/forums/viewtopic.php?t=217832
If you're stuck with dhclient and old versions of systemd, than use
ntpd or ntpdate, no problem.
>
> > > > moreover you want daemon.service to be part of the startup
> > > > transaction (I'm not certain why)
> > >
> > > Well, I'm not sure why I wouldn't.  The whole purpose of the
> > > system is to run that service.
> > But the trigger for the .service is not start up, but accessibilty
> > and if certain information are available.
>
> Other network-facing services e.g. sshd have WantedBy=multi-
> user.target - I don't see how my service is in principle
> different.  I just has some extra dependencies.
sshd.service is totaly fine by starting without network. It sounds like
your service needs a network and information from dhclient to be up
probably.
>
> > > Having to write looping shell-scripts or reinvent inotifywait
> > > seems contrary to the spirit of systemd, but maybe I have to do
> > > that.
> > You don't have to reinvent the wheel. You just need to know about
> > the capabilities of systemd.
>
> I'm trying to learn.  How can I get a systemd unit to defer its
> start until certain information is available from dhclient?
Well, in dhclient you can define a script which is executed as soon as
there is a lease. Use this to trigger further units as this is your
trigger. See man:dhclient-script
The normal start up logic is not appliable here. You want dhclient as
trigger after writing config files.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Deferring start of service until file exists

[Silvio Knizek]

Am Dienstag, den 20.08.2019, 16:32 +0100 schrieb Colin Hogben:
> Hi Jérémy, thanks for responding.
>
> > I'm not very clear on what you are trying to do, so if my
> > understanding
> > is correct:
>
> OK, I'll try to clarify.  In fact I'm lumping together several
> similar circumstances.  It's possible that for at least some of
> these, I'm not thinking about things in the right way.
Try to solve one problem at a time. Even if problems seems to be
similiar the can need different solutions.
>
> The broader context is a diskless server (NFS root) with potentially
> several instances whose configuration is managed through DHCP and/or
> kernel command-line options.
The NFS root needs to be mounted in the initrd step. Else everything
will break. With systemd in the initrd you gain the possibilty to
depend on those units in the actual system.
>
> One case is that I want to run rsyslogd with messages forwarded to an
> external server.  The server address is configured via a standard
> DHCP option.  My idea was to defer starting rsyslogd until the
> configuration had been set via the dhclient hook script.  On
> reflection, perhaps the dhclient script could do a "systemctl
> reload-or-try-restart rsyslog".  Another very similar case is time
> synchronisation, using chronyd.
Why not systemd-networkd, systemd-journald with remote-forwarding
enabled and systemd-timesyncd?
>
> But now we come to the nitty-gritty.  My application needs to
> interact with a hardware device and also needs some info from DHCP
> (essentially which hosts are allowed to talk to it).  In addition,
> the application executable and libraries are on a filesystem mounted
> from a location derived from DHCP.
Than your dhclient should start the network-online.target and you
should order everything accordingly. Or you use systemd-networkd which
already have a systemd-networkd-wait-online.service
>
> > moreover you want daemon.service to be part of the startup
> > transaction
> > (I'm not certain why)
>
> Well, I'm not sure why I wouldn't.  The whole purpose of the system
> is to run that service.
But the trigger for the .service is not start up, but accessibilty and
if certain information are available.
>
> > and not triggered on the file creation as a .path
> > unit would do.
>
> One key point is that there are other dependencies.
>
> My hope was that I would be able to implement most of this in the
> systemd declarative style - the application depends on a device, on
> the existence of a file and on a mounted filesystem.  I don't
> necessarily know in which order these things will appear, but systemd
> should sort it all out for me.
There are the proper dependencies. If you need network, there is the
network-online.target.
>
> > I would create an intermediate service wait_for_file.service that
> > would be Type=oneshot and would simply trigger some sort of shell
> > script waiting for trigger_file to appear and the terminate.
> >
> > daemon.service would have Wants=wait_for_file and
> > After=wait_for_file and you should be good.
>
> Having to write looping shell-scripts or reinvent inotifywait seems
> contrary to the spirit of systemd, but maybe I have to do that.
You don't have to reinvent the wheel. You just need to know about the
capabilities of systemd.
> Thanks for the suggestions.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Logs from a service is not showing up in journalctl but showing up in syslog

[Silvio Knizek]

Am Donnerstag, den 25.07.2019, 15:55 +0530 schrieb Debraj Manna:
> I have unit file which looks like below. I am seeing some of the echo
> are
> showing up in syslog but not in journalctl. Can someone let me know
> what is
> going on?
> systemd version 229 running on Ubuntu 16.
>
> [Unit]
> Description=Kafka Service
>
> [Service]
> Type=simple
> Environment=KAFKA_HOME=/home/ubuntu/deploy/kafka
> Environment=LIB_DIR=/var/lib/kafka
> Environment=LOG_DIR=/var/log/kafka
> Environment=TEMP_DIR=/home/ubuntu/tmp
> Environment=TOOLS_JAR=/home/ubuntu/build-target/common-utils/tools-
> 0.001-SNAPSHOT.jar
> Environment=MIN_DATA_PARTITION_FREE_SPACE_PCT=10
> Environment=MIN_DATA_PARTITION_FREE_SPACE_GB=10
> Environment=DATA_PARTITION_NAME=/var
>
> ExecStartPre=-/bin/mkdir -p /var/log/kafka
> ExecStartPre=-/bin/chown -R ubuntu:ubuntu /var/log/kafka
> ExecStartPre=-/bin/mkdir -p /var/lib/kafka/kafka-logs
> ExecStartPre=-/bin/chown -R ubuntu:ubuntu /var/lib/kafka/kafka-logs
> ExecStartPre=-/bin/rm -f /var/log/kafka/kafka-logs/.lock
> ExecStartPre=-/bin/mkdir -p /home/ubuntu/tmp
> ExecStartPre=-/bin/chown -R ubuntu:ubuntu /home/ubuntu/tmp
> ExecStartPre=-/bin/chmod -R 775 /home/ubuntu/tmp
> ExecStartPre=-/bin/su ubuntu -c
> "/home/ubuntu/build-target/kafka/kafka-systemd-prestart.sh"
> ExecStart=/bin/su ubuntu -c
> "/home/ubuntu/build-target/kafka/kafka-systemd-health.sh"
> ExecStopPost=-/bin/bash
> /home/ubuntu/build-target/kafka/kafka-systemd-poststop.sh
> RestartSec=2s
> Restart=always
> LimitNOFILE=65535
> KillSignal=SIGTERM
> SendSIGKILL=no
> SuccessExitStatus=1 143
>
> [Install]
> WantedBy=multi-user.target
>
> kafka-systemd-prestart.sh looks like below
>
> echo "[`date +"%h %d %Y %H:%M:%S-%3N"`] Starting kafka..."
> timeout --signal=sigkill 600s java -cp "$TOOLS_JAR"
> com.vnera.tools.kafka.KafkaIndexValidator "$LIB_DIR/kafka-logs"
> "$KAFKA_HOME/config/server.properties" true
> broker_id=`sudo grep -F "broker.id"
> $KAFKA_HOME/config/server.properties | awk -F '=' '{print $2}'`
> zookeeper_list=`sudo grep -F "zookeeper.connect="
> $KAFKA_HOME/config/server.properties | awk -F '=' '{print $2}'`
> echo "attempting removal of broker id $broker_id"
>
> used_pct=`df ${DATA_PARTITION_NAME} --output=pcent | grep -v Use |
> grep -o '[^ ]*[^ %]'`
> free_pct=$(expr 100 - $used_pct)
> free_gb=`df -h ${DATA_PARTITION_NAME} --output=avail --block-size G |
> grep -v Avail | grep -o '[^ ]*[^ G]'`
> echo "[`date +"%h %d %Y %H:%M:%S-%3N"`] partition
> ${DATA_PARTITION_NAME} free% $free_pct required%
> ${MIN_DATA_PARTITION_FREE_SPACE_PCT} freegb ${free_gb} required
> ${MIN_DATA_PARTITION_FREE_SPACE_GB}"
>
> # Some other code
>
> kafka-systemd-poststop.sh looks like below
>
> ---
>
> echo "[`date +"%h %d %Y %H:%M:%S-%3N"`] Exiting kafka..."
> cmd="ps -ef | grep -v grep | grep kafkaServer"
>
> # Some other code
>
> echo "completed exiting kafka"
>
> Doing sudo journalctl -u kafka.service looks like below
>
> Jul 25 07:41:39 platform2 systemd[1]: Started Kafka Service.
> Jul 25 07:41:39 platform2 su[39160]: Successful su for ubuntu by root
> Jul 25 07:41:39 platform2 su[39160]: + ??? root:ubuntu
> Jul 25 07:41:39 platform2 su[39160]: pam_unix(su:session): session
> opened for user ubuntu by (uid=0)
> Jul 25 07:41:40 platform2 bash[39192]: [Jul 25 2019 07:41:40-572]
> Exiting kafka...
>
> I am not seeing some of the echo from kafka-systemd-prestart.sh in
> journatl but I am seeing those logs in syslog
>
> Jul 25 10:17:03 platform2 su[38464]: WatchedEvent state:SyncConnected
> type:None path:null
> Jul 25 10:17:03 platform2 su[38464]: Node does not exist:
> /brokers/ids/2
> Jul 25 10:17:03 platform2 su[38464]: [Jul 25 2019 10:17:03-343]
> partition /var free% 9 required% 10 freegb 134 required 10
> Jul 25 10:17:03 platform2 su[38464]: [Jul 25 2019 10:17:03-344]
> Sufficient disk space is not available, sleeping for 60 seconds
> before
> exiting...

Hi,

first of all, take a look at man:tmpfiles.d to replace the whole
mkdir/chmod ExecStartPre= stuff.
Second, don't use »su« in .service. It breaks stuff by creating a new
cgroup hierarchy because it's run through pam. Use User= instead.
With both this changes your shell scripts shouldn't be necessary at all
and than everything should land in the journal.
Please don't re-invent the stuff systemd is already providing.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] failing unmounts during reboot

[Silvio Knizek]

Am Donnerstag, den 25.07.2019, 11:40 +0200 schrieb Frank Steiner:
> Hi,
>
> I'm currently discussing a problem with the SuSE support about
> failing
> unmounts during reboot. Tyring to debug this I realized that systemd
> is not killing processes left over by some init.d script. E.g. use
> the following script in /etc/init.d/
>
> #!/bin/sh
> #
> ### BEGIN INIT INFO
> # Provides: bla
> # Required-Start: $network $remote_fs sshd
> # Required-Stop: $network $remote_fs sshd
> # Default-Start:  2 3 5
> # Description:test
> ### END INIT INFO
> case "$1" in
>   start) cd /test; /usr/bin/sleep 99d & ;;
>stop) true;;
> esac
>
>
> On shutdown, unmounting /test will fail because the sleep process is
> not killed. Shouldn't there be a mechanism in system to kill
> processes
> spawned by LSB script when shutting these down?
>
> And moreover, wouldn't it make sense to have a mechanism to at least
> try to kill all processes using a filesystem before unmounting it?
> We often see failing unmounts of several local or iscsi fs during
> reboot, and in the support case we are currently working on with SuSE
> failing iscsi fs even cause xfs I/O errors. So it might be a good
> idea
> to have sth. like a lsof + kill before unmounting a filesystem, maybe
> configurable with a flag to enable or disable it. Even if lsof or
> kill
> failed, it wouldn't be worse than now.
>
> As far as I see there is no way to write a drop-in for a mount unit
> that allows to execute commands before the unmount happens, is that
> right? Sth. like "ExecPreUmount=" would help here, especially if
> there
> was sth. like a umount@.service that would be called for every umount
> with e.g. the mounpoint accessable with a variable.
>
> cu,
> Frank
>
Hi,

the proper approach would be to define the dependency of the generated
.service to the mount point with a drop-in and RequiresMountsFor=. See
man:systemd.unit for more information.
Also the systemd-sysv-generator can only do so much. Please write
yourself proper units if you encounter problems.

BR
Silvio

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vconsole for handicapped or older people

[Silvio Knizek]

Am Montag, den 22.07.2019, 18:49 +0200 schrieb hp hpf:
>
> Silvio Knizek  schrieb am Mo., 22. Juli 2019,
> 13:55:
>
> > Am Montag, den 22.07.2019, 13:20 +0200 schrieb hp4everything:
> > > Hi,
> > >
> > > getting older I'm nearly not able to read the text on a virtual
> > > console.
> > > I'm working with opensuse tumbleweed on a laptop and was able to
> > > configure the KDE screen for my needs, but not the vconsole.
> > >
> > > Google told me that probably systemd is responsible for vconsole-
> > > configuration, but in vconsole.conf there seem to be options for
> > > me
> > > to make the text readable:
> > >
> > > - the preconfigured font "eurlatgr" has no fontsize-option
> > > - vconsole.conf has no fontsize-parameter
> > > - vconsole.conf has no screen-resolution parameter
> > > - vconsole.conf has no parameter to select a framebuffer, e.g
> > > 1052x768
> > >
> > >
> > > can anybody help with links to more detailed documentation or
> > > with
> > > hints
> > > how to configure vconsole in systemd/Opensuse Tumbleweed?
> > >
> > > Thanks
> > > Hans-Peter
> >
> > Hi,
> >
> > I think your best try would by kmscon [1], which replaces your
> > normal
> > TTY with something using proper font scaling and such.
> >
> > HTH
> > Silvio
> >
> > [1]: https://www.freedesktop.org/wiki/Software/kmscon/
> Hi Silvio,
>
> Thanks for youre recommendation.
>
> Do you also have  a link to more detailed instructions or did
> I  miss it on the kmscon-homepage?
>
> Is simple installation in tumbleweed  sufficient to  replace all
> F1-F6-terminals or  do  I  have to  configure every single terminal
> in systemd-files?
>
> Tanks in Advanced
> Hans-Peter
>
Hi Hans-Peter,

please follow the instructions in the wonderfull Arch Linux wiki [1].
Also please don't answer off-list.

BR
Silvio

[1]: https://wiki.archlinux.org/index.php/KMSCON

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vconsole for handicapped or older people

[Silvio Knizek]

Am Montag, den 22.07.2019, 13:20 +0200 schrieb hp4everything:
> Hi,
>
> getting older I'm nearly not able to read the text on a virtual
> console.
> I'm working with opensuse tumbleweed on a laptop and was able to
> configure the KDE screen for my needs, but not the vconsole.
>
> Google told me that probably systemd is responsible for vconsole-
> configuration, but in vconsole.conf there seem to be options for me
> to make the text readable:
>
> - the preconfigured font "eurlatgr" has no fontsize-option
> - vconsole.conf has no fontsize-parameter
> - vconsole.conf has no screen-resolution parameter
> - vconsole.conf has no parameter to select a framebuffer, e.g
> 1052x768
>
>
> can anybody help with links to more detailed documentation or with
> hints
> how to configure vconsole in systemd/Opensuse Tumbleweed?
>
> Thanks
> Hans-Peter

Hi,

I think your best try would by kmscon [1], which replaces your normal
TTY with something using proper font scaling and such.

HTH
Silvio

[1]: https://www.freedesktop.org/wiki/Software/kmscon/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] non-dev systemd-devel package for Linux

[Silvio Knizek]

I think you got the point of -devel packages wrong.
A -devel package does not contain the development version (a.k.a.
something unstable) of an application, but everything you need to
develop against an application. Like header files. They are stripped
out on RHEL/CentOS in its own package to reduce package size and
because you don't need them normally.
With "rpm -ql systemd-devel" you see which files are in the package.

HTH
Silvio

Am Freitag, den 31.08.2018, 10:52 -0700 schrieb Sayeed hyder:
> Thanks Silvio. Unfortunately, I cannot use devel. IIUC, rhel/centos
> does
> not provide a non-dev systemd package? That does not sound right.
> 
> On Fri, Aug 31, 2018 at 10:35 AM, Silvio Knizek  >
> wrote:
> 
> > Hi Sayeed,
> > 
> > it is expected that header files are in the -devel packages. You
> > can't
> > change this. The package "systemd" contains "udev", so in "systemd-
> > devel" are the header files for "udev". "udev" is part of systemd.
> > RHLE/CentOS don't split this.
> > 
> > Why can't you just use "systemd-devel"? It just contains everything
> > you
> > need to be able to compile against systemd and udev (and maybe
> > more).
> > 
> > BR
> > Silvio
> > 
> > Am Freitag, den 31.08.2018, 10:29 -0700 schrieb Sayeed hyder:
> > > I tried Mantas's suggestion and try to install "yum install
> > > libudev.so.1" which shows me "Package systemd-libs-219-
> > > 57.el7_5.1.i686 already installed and latest version". Here is
> > > the
> > > list of systemd packages already installed in my rhel vm. When I
> > > use
> > > libudev.h in my program, it cannot compile ("no such file or
> > > directory").
> > > 
> > > But if i do "yum install libudev-devel", it installs systemd-
> > > devel.x86_64 0:219-57.el7_5.1, and I can compile fine. So, the
> > > problem seems to be the difference between package systemd-
> > > devel.x86_64 0:219-57.el7_5.1 and package systemd-219-
> > > 57.el7_5.1.x86_64. In the latter one, the libudev.h header file
> > > is
> > > not exposed for use. I cannot use the "devel" version.
> > > Any suggestion?
> > > 
> > > 
> > > thanks,
> > > Sayeed
> > > 
> > > 
> > > On Fri, Aug 31, 2018 at 10:05 AM, Ryan Gonzalez  > > >
> > > wrote:
> > > 
> > > > Isn't it just "libudev", e.g. without the 1?
> > > > 
> > > > 
> > > > On Fri, Aug 31, 2018, 11:19 AM Sayeed hyder  > > > >
> > > > wrote:
> > > > 
> > > > > Thanks Reindl. Let me be a bit more specific. I am looking
> > > > > for
> > > > > the
> > > > > non-dev package. For example, for ubuntu and sles, I can do
> > > > > the
> > > > > followiing
> > > > > 
> > > > > apt-get install libudev1 works
> > > > > zypper install libudev1 works
> > > > > 
> > > > > But, for rhel,
> > > > > yum install libudev1    cannot find package
> > > > > yum install libudev-devel works
> > > > > 
> > > > > Is there any runtime (non-dev) package for rhel/centos
> > > > > distro? If
> > > > > so,
> > > > > what is the package name I should look for?
> > > > > 
> > > > > 
> > > > > thanks,
> > > > > Sayeed
> > > > > 
> > > > > 
> > > > > On Fri, Aug 31, 2018 at 8:24 AM, Reindl Harald <
> > > > > h.rei...@thelounge.net>
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Am 31.08.18 um 16:51 schrieb Sayeed hyder:
> > > > > > > Where can I get the link of available non-dev packages
> > > > > > > for
> > > > > > > different
> > > > > > > Linux distros? I am specifically looking for rhel
> > > > > > > version  of
> > > > > > > libudev
> > > > > > > package.
> > > > > > 
> > > > > > from the package repo of teh distribution?
> > > > > > just download the CentOS one which is identical to RHEL
> > > > > > ___
> > > > > > systemd-devel mailing list
> > > > > > systemd-devel@lists.freedesktop.org
> > > > > > 
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > > > > > 
> > > > > 
> > > > > ___
> > > > > systemd-devel mailing list
> > > > > systemd-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > > > > 
> > > > 
> > > > --
> > > > 
> > > > Ryan (ライアン)
> > > > Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >>
> > > > everyone
> > > > else
> > > > https://refi64.com/
> > > > 
> > > 
> > > ___
> > > systemd-devel mailing list
> > > systemd-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > 
> > 
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] non-dev systemd-devel package for Linux

[Silvio Knizek]

Hi Sayeed,

it is expected that header files are in the -devel packages. You can't
change this. The package "systemd" contains "udev", so in "systemd-
devel" are the header files for "udev". "udev" is part of systemd.
RHLE/CentOS don't split this.

Why can't you just use "systemd-devel"? It just contains everything you
need to be able to compile against systemd and udev (and maybe more).

BR
Silvio

Am Freitag, den 31.08.2018, 10:29 -0700 schrieb Sayeed hyder:
> I tried Mantas's suggestion and try to install "yum install
> libudev.so.1" which shows me "Package systemd-libs-219-
> 57.el7_5.1.i686 already installed and latest version". Here is the
> list of systemd packages already installed in my rhel vm. When I use
> libudev.h in my program, it cannot compile ("no such file or
> directory").
> 
> But if i do "yum install libudev-devel", it installs systemd-
> devel.x86_64 0:219-57.el7_5.1, and I can compile fine. So, the
> problem seems to be the difference between package systemd-
> devel.x86_64 0:219-57.el7_5.1 and package systemd-219-
> 57.el7_5.1.x86_64. In the latter one, the libudev.h header file is
> not exposed for use. I cannot use the "devel" version.
> Any suggestion?
> 
> 
> thanks,
> Sayeed
> 
> 
> On Fri, Aug 31, 2018 at 10:05 AM, Ryan Gonzalez 
> wrote:
> 
> > Isn't it just "libudev", e.g. without the 1?
> > 
> > 
> > On Fri, Aug 31, 2018, 11:19 AM Sayeed hyder 
> > wrote:
> > 
> > > Thanks Reindl. Let me be a bit more specific. I am looking for
> > > the
> > > non-dev package. For example, for ubuntu and sles, I can do the
> > > followiing
> > > 
> > > apt-get install libudev1 works
> > > zypper install libudev1 works
> > > 
> > > But, for rhel,
> > > yum install libudev1    cannot find package
> > > yum install libudev-devel works
> > > 
> > > Is there any runtime (non-dev) package for rhel/centos distro? If
> > > so,
> > > what is the package name I should look for?
> > > 
> > > 
> > > thanks,
> > > Sayeed
> > > 
> > > 
> > > On Fri, Aug 31, 2018 at 8:24 AM, Reindl Harald <
> > > h.rei...@thelounge.net>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > Am 31.08.18 um 16:51 schrieb Sayeed hyder:
> > > > > Where can I get the link of available non-dev packages for
> > > > > different
> > > > > Linux distros? I am specifically looking for rhel version  of
> > > > > libudev
> > > > > package.
> > > > 
> > > > from the package repo of teh distribution?
> > > > just download the CentOS one which is identical to RHEL
> > > > ___
> > > > systemd-devel mailing list
> > > > systemd-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > > > 
> > > 
> > > ___
> > > systemd-devel mailing list
> > > systemd-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > > 
> > 
> > --
> > 
> > Ryan (ライアン)
> > Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
> > else
> > https://refi64.com/
> > 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Not able to access system device from session service

[Silvio Knizek]

Am Montag, den 20.08.2018, 19:22 +0530 schrieb deepan muthusamy:
> I started one application as system service in /etc/systemd/system by
> giving command "systemctl  start mysystem.service".
> I have one more application which i have to start as session service
> in etc/systemd/user by giving command "systemctl --user start
> mysession.service".
> 
> My session.service  has dependency on mysystem.service, so I
> mentioned in Requires and After command in session.service.
> 
> But when iam trying to session.service it is showing
> "mysystem.service" not found. Can anyone help me with this?

Hi,

the systemd --user session don't know about the systemd --system
session (and vice versa). So you can't have dependencies among them.
They are completly seperated (except for .device and .mount units)

BR

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting a service as user instead as root

[Silvio Knizek]

Am Montag, den 13.08.2018, 11:28 +0200 schrieb Cecil Westerhof:
> I have a service that is run as a different user as root. But only
> root can
> restart the service. Is there a way to make 'systemctl restart' work
> for
> the user that runs the service?

Hi,

you can either define a sudo-rule or you use policykit (polkit) for
this. See 
https://wiki.archlinux.org/index.php/Polkit#Allow_management_of_individual_systemd_units_by_regular_users
 for an example. Keep in mind that the polkit feature depends on your
available systemd version.

BR

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Local mount as a remote-fs?

[Silvio Knizek]

Am Montag, den 04.12.2017, 14:25 +0300 schrieb Andrey Klimentyev:
> Hi,
> 
> Is it possible to register local mount as a remote-fs?
> 
> I've got a rather peculiar problem with Kubernetes and Ceph:
> 1. kubelet creates an rbd device in /dev;
> 2. it mounts it to some location;
> 3. systemd adds local-fs.target and local-fs-pre.target to  Before=
> and
> After= directives on auto-created .mount Units.
> 
> Unfortunately, with that approach thing get rather messy on shutdown.
> Ceph
> RBD kernel client detects network outage (since we've already
> disabled the
> network) and stops all I/O to those filesystems, while systemd
> actively
> tries to umount them. systemd depends on umounting those filesystems,
> and
> Ceph depends on an online network to properly finish all I/O and
> unmount
> them, thus creating a kind of a deadlock.

Hi,

use the mount option »_netdev«, which declares a device as dependent on
network. See »man mount« for more information.

BR
Silvio
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl can't execute stop actually, when service is started by other way

[Silvio Knizek]

Am Dienstag, den 27.06.2017, 13:48 +0800 schrieb 清辰:
> for example: service nscd
> 1.execute: systemctl stop nscd.service
>   stop nscd process actually
> 2.execute: /usr/bin/nscd
>   start nscd by shell command
> 3.execute: systemctl status nscd.service
>   inactive(dead)
>   systemctl can't know nscd is running
> 4.excute: systemctl stop nscd.service
>   nscd process still exist, it seems that systemctl does not execute
> stop actually
> 
> 
> How can I stop nscd.service by systemctl when it is started not by
> systemctl?
> 
> 
> Why I need stop nscd.service by systemctl? 
> Because when linux reboot or shut down, linux will auto stop service
> by 'systemctl stop nscd.service'.
> If 'systemctl stop nscd.service' does not stop service actually, my
> service will exit abnormally. That may lead data loss in my service.
> 
> 
> Thank you very much

Hi,

you can't. Only services started by systemd are properly stopped by
systemd. Everything else will be killed during the last killing spree.
Also please keep in mind that processes you started on a shell might be
 killed as soon as the user logs out the shell belongs to. Or when the
users session is stopped.

BR
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] template service unit include.d directory

[Silvio Knizek]

Am Mittwoch, den 03.05.2017, 19:51 +0530 schrieb Anoop Alias:
> Hi,
> 
> I am trying to include extra config for a template service file
> 
> PHP70@.service
> 
> ##
> 
> I created /etc/systemd/system/PHP70@.service.d/something.d/t
> est.conf
> 
> But
> 
> systemctl start PHP70@something.service
> 
> does not include the file test.conf
> 
> According to the doc:
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> 
> "Along with a unit file foo.service, a "drop-in" directory
> foo.service.d/
> may exist. All files with the suffix ".conf" from this directory will
> be
> parsed after the file itself is parsed. This is useful to alter or
> add
> configuration settings for a unit, without having to modify unit
> files.
> Each drop-in file must have appropriate section headers. Note that
> for
> instantiated units, this logic will first look for the instance ".d/"
> subdirectory and read its ".conf" files, followed by the template
> ".d/"
> subdirectory and the ".conf" files there"
> 
> What am I doing wrong here?
> 
> # systemctl --version
> systemd 219
> +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
> +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
> 
> OS: CentOS Linux release 7.3.1611 (Core)
> 
> 
> Thanks in advance

Hi Anoop,

the right directory for your drop-in is /etc/systemd/system/PHP70@somet
hing.service.d/
Use »systemctl cat PHP70@something« to see what is parsed.

BR
Silvio
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel