[systemd-devel] Missing PropertiesChanged signal for service start

[ashitha v via systemd-devel]

Hi,

I have a service file as follows:

[Unit]
Description= "Daemon description"
After=a.service

b.service 

c.service 

OnFailure=failure_handler@%p.service


[Service]
WorkingDirectory=/usr/sbin

ExecStartPre=/bin/sleep

30
ExecStart=


When this service starts I expected a signal indicating state=active.
When I reboot the system multiple times, the signal indicating
"active" is missing some times.

I got the signal ActiveState=activating, SubState=start-pre at all
times. But signal indicating ActiveState="active" and
SubState="running" was missing for some reboots.

The service is running and shows active state all the time. What is
reason for missing signal? I am also checking if the sleep in the
ExecStartPre is required for this

service. I am wondering if that has something to do with the missing signal.


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

Re: [systemd-devel] Starting services enabled by filesystem overlay over /etc/

[Matt Schuckmann]

Thank you all for the responses.

It sounds like I should look into creating an initramfs to mount my writable 
partitions and /etc overlay. I've never created an initramfs so it might take 
me a bit to work through it.


In the mean time I've found that masking services does work with my overlay for 
enabling or disabling services. So my plan now is to leave the service enabled 
in the read-only rootfs and then mask or unmask it in the /etc overlay.  This 
seems to be a reasonable workaround until I can get an initramfs in place; 
unless one of you helpful people tells me otherwise.


Thanks,

Matt S.


[PS I hope this gets added to the correct thread, I'm only receiving digests 
and I'm not sure how best to respond].
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mount a remote FS as a user

[Lennart Poettering]

On Mo, 11.02.19 15:59, Daniel Tihelka (dtihe...@gmail.com) wrote:

> Hello,
> I can mount a shared file system (sshfs in particular) as an ordinary user.
>
> Now I would like to have it handled by systemd on-demand (automount).
> However, creating the automount unit and starting it fails with error:

autofs (the kernel subsystem behin the .automount unit type) is
accessible to privileged clients only, and systemd --user is not
privileged in general. This means what you are trying to do is simply
not supported by the kernel.

We could start supporting this if the kernel would open up autofs for
unpriv clients, like it did for fuse mounts. However, I don't see that
happening any time soon.

Sorry!

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting services enabled by filesystem overlay over /etc/

[Lennart Poettering]

On So, 10.02.19 17:28, Mantas Mikulėnas (graw...@gmail.com) wrote:

> On Sun, Feb 10, 2019 at 10:07 AM Andrei Borzenkov 
> wrote:
>
> > 09.02.2019 21:45, Matt Schuckmann пишет:
> > >
> > > What do I need to do to get systemd to automatically start the services
> > that are marked enabled in that overlay?
> > >
> >
> > I am not aware of any clean way to do it. Attempting to re-queue start
> > of default.target will likely be noop as this request is already queued.
> >
> > The only workaround I can think of is to make initial boot into target
> > that mounts overlay and then triggers start of actual default target.
> >
>
> In other words, do it from an initramfs.

Yes, this is the way to go.

In context of this: we hopefully will merge this soon:

https://github.com/systemd/systemd/pull/11243

If it is merged systemd can set up the overlayfs for the root fs
automatically for you in the initrd, without any manual scripting.

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Mount a remote FS as a user

[Daniel Tihelka]

Hello,
I can mount a shared file system (sshfs in particular) as an ordinary user.

Now I would like to have it handled by systemd on-demand (automount).
However, creating the automount unit and starting it fails with error:

~ $ systemctl --user status run-mount-dt-ARTIC.automount
● run-mount-dt-ARTIC.automount - Automatic mount the shared folder
   Loaded: loaded
(/home/dt/.config/systemd/user/run-mount-dt-ARTIC.automount; enabled;
vendor preset: enabled)
   Active: failed (Result: resources)
Where: /run/mount/dt/ARTIC

I have an access to the required mount point:

~ $ touch /run/mount/dt/ARTIC/XXX
~ $ echo $?
0
~ $ rm /run/mount/dt/ARTIC/XXX
~ $ echo $?
0

and also invoking sshfs directly works without problems (it uses key
stored in the ssh-agent).

The unit looks as follows:

~ $ cat ~/.config/systemd/user/run-mount-dt-ARTIC.automount
[Unit]
Description=Automatic mount the shared folder

[Automount]
Where=/run/mount/dt/ARTIC
DirectoryMode=0700
TimeoutIdleSec=6000

[Install]
WantedBy=default.target


~ $ cat ~/.config/systemd/user/run-mount-dt-ARTIC.mount
[Unit]
Description=Mounts the shared folder

[Mount]
What=pole:/data-ntis/projects/ARTIC/
Type=fuse.sshfs
TimeoutSec=6000

systemd 239
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid


Is there something I am doing wrong, or is it the user-instance of
systemd which is unable to mount the path? Unfortunately, I don't have
root access to put it into the /etc/fstab, but I would suppose it
should work anyway when I am able to run it manually.


Thank you
DT


P.S. The different (but somehow similar) story is the mount of cifs
share. It requires the root access, but I can't see a security issue
of mounting a remote FS when I can authenticate myself ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting services enabled by filesystem overlay over /etc/

[Jonathon Kowalski]

On Sunday, February 10, 2019, Andrei Borzenkov  wrote:

> 09.02.2019 21:45, Matt Schuckmann пишет:
> > I have an embedded system with a readonly rootfs.
> >
> > I've setup a very early service that mounts a writable aufs overlay over
> /etc/.
> >
> >
> > The problem I'm having is systemd is not starting any services that I
> have enabled in that overlay that were not initially enabled in the
> readonly rootfs.
> >
> > ?I've tried placing a calls to systemctl daemon-reload or systemctl
> daemon-reexec just after mounting the overlay but the services are not
> started, after the fact systemctl will report that the services are enabled
> but inactive.
> >
>
> If you are doing it as part of normal startup, then systemd has already
> computed initial "transaction". While daemon-reload makes it rescan for
> and see additional unit definitions, it does not change currently
> running "transaction".
>
> >
> > What do I need to do to get systemd to automatically start the services
> that are marked enabled in that overlay?
> >
>
> I am not aware of any clean way to do it. Attempting to re-queue start
> of default.target will likely be noop as this request is already queued.


Unless I am misunderstanding something (in the code), it wouldn't be a
noop. After the reload/reexec, systemd should have updated the
Wants=/Requires= property of target. Now, the transaction that was
activated previously will not change based on this (because it was computed
in the past, checked for consistency, minimised for impact, jobs
merged/collapsed and then activated). At this point, there isn't even a
transaction, it's just a set of jobs installed on units waiting on each
other in run queue.

However, systemd, if you happen to trigger a start job on default.target
replacing the installed job now, will compute a transaction again, and
trigger jobs for everything again. Since this is all across transactions,
this will result in another transaction being applied, duplicate jobs
produced in both getting merged in installed one, but also the enabled
units starting up, with new jobs installed for those.

So invoking a 'systemctl start default.target --job-mode replace' again
will make the enabled units start up.

However, this has one disadvantage: You may end up having start jobs
triggered for already started->inactive units again (think oneshots)
(because there jobs slots are free after it finishing, so nothing to
coalesce, hence a trigger again). For running units, state change is noop
so it installs and finishes immediately. Where this can be surprising is
later activation triggers a stop job for some unit enabled on boot (through
Conflicts=, PartOf=), and then you end up trigger a start for it again,
producing incorrect results.

Still, all this said, it would be more correct to do it from initramfs as
grawity suggests, and then have all of this computed as part of initial
transaction at boot.

>
> The only workaround I can think of is to make initial boot into target
> that mounts overlay and then triggers start of actual default target.
> ___
> 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] Possible race condition with LVM activation during boot

[suscricions]

El Thu, 07 Feb 2019 22:51:17 +0100
Martin Wilck  escribió:

> On Thu, 2019-02-07 at 19:13 +0100, suscrici...@gmail.com wrote:
> > El Thu, 7 Feb 2019 11:18:40 +0100
> > 
> > There's been a reply in Arch Linux forums and at least I can apply
> > some
> > contingency measures. If it happens again I will provide more info
> > following your advice.  
> 
> The log shows clearly that the device was available first:
> 
> feb 06 12:07:09 systemd[1]: Starting File System Check
> on /dev/disk/by-uuid/cabdab31-983b-401f-be30-dda0ae462080... feb 06
> 12:07:09 systemd-fsck[520]: multimedia: limpio, 1051/953984 ficheros,
> 193506294/244189184 bloques feb 06 12:07:09 systemd[1]: Started File
> System Check
> on /dev/disk/by-uuid/cabdab31-983b-401f-be30-dda0ae462080.
> 
> That wouldn't be possible without the device being visible to the
> system. Shortly after you get
> 
> feb 06 12:07:09 mount[544]: mount: /mnt/multimedia: el dispositivo
> especial /dev/disk/by-uuid/cabdab31-983b-401f-be30-dda0ae462080 no
> existe.
> 
> ... So the device that had already been visible must have disappeared
> temporarily. After the mount failure, we see messages about the LV
> becoming active:
> 
> [...]
> feb 06 12:07:09 lvm[483]:   1 logical volume(s) in volume group
> "storage" now active [...]
> feb 06 12:07:09 lvm[494]:   1 logical volume(s) in volume group
> "storage" now active
> 
> There are two "lvm pvscan" processes (483 and 494) that may be
> interfering with each other and/or with the "mount" process. These
> processes are running on 8:17 (/dev/sdb1) and 254:1. I couldn't
> figure out from your logs what this latter device might be. 
> 
> Wild guess: the pvscan processes working on the VG while it's already
> visible are causing the device to get offline for a short time span,
> and if the mount is attempted in that time window, the error occurs.
> 
> There's another lvm process (340) started earlier by the lvm2-monitor
> unit ("Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or
> progress polling."). Immediately after termination of this process,
> the device seems to be detected by systemd and the above fsck/mount
> sequence begins, while the pvscan processes are still running. "lvm2-
> monitor.service" runs "vgchange --monitor y". It almost looks as if
> this had caused the devices to be visible by systemd, but that would
> be wrong AFAICT.
> 
> Can you reproduce this with "udev.log-priority=debug"?
> 
> Regards,
> Martin
> 
> 
> 

Hi Martin,

Do you want me to send the log of a clean boot with udev priority in
debug? I've tried to paste it on termbin.com but it's too big. When
gzipped it's around 140 KB. Maybe I can just paste it as binary hehe.

You tell me.


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