Re: [systemd-devel] elegant way to use a single mount unit file for multiple paths
You can't use templates with .mount units because .mount units need to be
named exactly after their mount point.
That's probably not explicitly documented, but might be a good idea to add.
For your use-case, I would probably use a generator (man systemd.generator)
to solve that...
It might not solve your problem, since we don't know when exactly do the
mount themselves happen but it would work for the simple, mount at boot,
case
HtH
Jeremy
Le jeu. 23 janv. 2020 à 18:30, Marcel Partap a écrit :
> Salut,
> for our live debian USB stick distro for students (
> https://github.com/fsfw-dresden/usb-live-linux ), we want to minimize on
> flash writes by putting several paths into a tmpfs overlay. So there is a
> pre-overlay@.service with
>
> > [Unit]
> > Description=Prepare writable overlay on %f
> > DefaultDependencies=no
> > RequiresMountsFor=/run
> >
> > [Service]
> > Type=oneshot
> > ExecStart=/bin/mkdir -p '/run%f'
> > ExecStart=/bin/mount -t tmpfs -o noatime tmpfs '/run%f'
> > ExecStart=/bin/mkdir -p '/run%f/work' '/run%f/rw'
>
> and f.e. a var-lib-apt-lists.mount with
> > [Unit]
> > Description=tmpfs overlay of %f
> > Conflicts=umount.target
> > Wants=pre-overlay@%p.service
> > After=pre-overlay@%p.service
> >
> > [Mount]
> > What=overlay
> > Type=overlay
> > Where=%f
> > Options=lowerdir=%f,upperdir=/run%f/rw,workdir=/run%f/work
> >
> > [Install]
> > WantedBy=local-fs.target
>
> Currently, the file is just cloned for multiple paths, which is working
> but not very elegant. I tried changing it into an instanced unit file
> tmpfs-overlay@.mount, which did not work ("Unit type mount cannot be
> templated" in journal only, nothing from systemd-analyze verify or the
> systemd.mount man page).. Neither did calling the file
> tmpfs-overlay.mount.unit and symlinking to it as var-lib-apt-lists.mount,
> var-cache-apt.mount etc.
>
> So what would be a more elegant way to not have multiple copies of the
> very same file?
>
> Best Regards,
> #marcel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
[image: SMILE] [image: Facebook]
[image: LinkedIn]
[image: Github]
[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Conditional dependency
Hi, Is there a way to specify conditional dependency in service files ? My use case is : I have a include file my.include that contains 'After=core.service' among other things. I have services A,B,C and X. As of now , all include my.include. Now my requirement is - I want services A,B and C to be dependent on core.service but X service should not depend on core.service.one solution i thought is - Instead of include my.include in all 4 services, I can create 2 separate include files and include appropriate files in those services. Is there any other better way ? Regards Prashant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] making journald logs persistent on raspberry pi
On Fri, 24 Jan 2020 18:36:49 +0200 Mantas Mikulėnas wrote: > On Fri, Jan 24, 2020 at 5:32 PM Dave Howorth > wrote: > > > It's quite common on the Raspberry Pi to make /var/log a tmpfs, in > > order to reduce the number of writes to the SD card that is the pi's > > main storage. That's quite acceptable for most logs but I'd like to > > make journald's logs persistent so I'll be able to investigate any > > problems that occur whilst booting or shutting down more easily. > > > > My first thought was to configure journald to write the log > > somewhere else, but it seems there's no possibility to do that? > > (why not?) > > > > So I think I will need to create /var/log/journal as a symlink to a > > directory in a permanent filesystem. The symlink needs to be created > > after the tmpfs is created but before journald starts (or else > > journald will need to be told to notice the change). > > > > My systemd foo isn't up to that and a web search hasn't found an > > answer. What's the best way to do it please? > > > > Mount --bind a persistent directory on top of /var/log/journal, using > the same method that you currently use for mounting the tmpfs. Many thanks for that. Obvious with the benefit of hindsight, but wasn't to me at the time:) I've come to realize that an equally interesting question is where to put the logs? Somewhere under /var/lib seems closest but FHS 3 specifically says; "This hierarchy holds state information pertaining to an application or the system. ... should not be logging output ...". Does anybody here have any thoughts? I'll ask on the fhs list as well. Thanks, Dave > -- > Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-resolved LLMNR keeps switching between ipv4 and ipv6
Hi, everybody! After switching to systemd-resolved I've discovered that local address resolution uses only LLMNR which causes some inconvenience. Resolving local network host names constantly jumps between ipv4 and ipv6. It is something like 2 minutes ping resolves ipv4 address and 2 other minutes ipv6 addresses. I've looked at what happens at the network level and found that upon resolution systemd-resolved send 2 broadcast requests - one for ipv4 and one for ipv6 and uses the response which comes first. The problem is that sometimes it sends ipv4 request first and sometimes ipv6 which affects the order in which responses are returned. -- Regards, Georgy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus activation service path
Also not related to my question, but a dbus-broker behavior/bug that causes flatpak to misbehave: https://github.com/flatpak/flatpak/issues/3342 On Fri, Jan 24, 2020 at 11:27 PM Damian Ivanov wrote: > > Hello! > > Thank you for all the great work! > Can't wait to test systemd-homed. > > I also have a question about dbus activation. > Is there an environment variable or something to tell systemd/dbus-broker &co > to look in a specific path for dbus .service files? > > I have a .desktop file which requires dbus activation but the .service > can not be in > any standard path and I want to let the .desktop file know where to > look for the dbus .service file. > > Any suggestions? > > br, > Damian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] detect_container() for recent(?) docker
Hello,
I've just found that an assumption used inside detect_container() is
not always true, and that leads to virtualization misdetection.
Namely, I am running systemd inside docker (19.03.5) container on
ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
/* Interestingly /proc/1/sched actually shows the host's PID
for what we see as PID 1. If the PID
* shown there is not 1, we know we are in a PID namespace and
hence a container. */
check_sched:
r = read_one_line_file("/proc/1/sched", &m);
However, I see the following when reading this file in the container:
64813fe8f025:/ # cat /proc/1/sched
bash (1, #threads: 1)
---
Unfortunately, this leads to virtualization misdetection on systemd
startup (docker host runs inside kvm):
Detected virtualization kvm.
And that leads to the issues with getty-generator which tries to use
host serial tty devices.
Running the same docker container with "-e container=docker"
explicitly resolves both issues.
--
With best regards,
Matwey V. Kornilov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
