Re: [systemd-devel] Missing PropertiesChanged signal for service start

[ashitha v via systemd-devel]

Hi Lennart,

I missed some details in the previous mail.
This is seen on systemd 230. Unfortunately, I cannot do a systemd upgrade
now.

Subscribe() is done on org.freedesktop.systemd1 path
=/org/freedesktop/systemd1 intf =org.freedesktop.systemd1.Manager. To make
sure that the signal was not missed due to an error in the Subscribe()
logic, I also ran a dbus-monitor script that runs "/usr/bin/dbus-monitor
--system" and redirects it to a dbus-monitor log file. The dbus-monitor
script is always guaranteed to run before the service in question so it
doesn't miss any signal. I don't see any signal indicating active state in
the dbus-monitor log file when the issue happens.

Thanks
Ashitha

On Tue, Feb 12, 2019 at 2:14 AM Lennart Poettering 
wrote:

> On Mo, 11.02.19 19:50, systemd Mailing List (
> systemd-devel@lists.freedesktop.org) wrote:
>
> > Hi,
> >
> > I have a service file as follows:
> >
> > [Unit]
> > Description= "Daemon description"
> > After=a.service
> > <
> https://opengrok-evo.juniper.net/source/s?path=mgd.service=EVO_TOT
> >
> > b.service <
> https://opengrok-evo.juniper.net/source/s?path=mgd-api.service=EVO_TOT
> >
> > c.service <
> https://opengrok-evo.juniper.net/source/s?path=jsd.service=EVO_TOT
> >
> > OnFailure=failure_handler@%p.service
> > <
> https://opengrok-evo.juniper.net/source/s?path=p.service=EVO_TOT>
> >
> > [Service]
> > WorkingDirectory=/usr/sbin
> > <
> https://opengrok-evo.juniper.net/source/s?path=/usr/sbin=EVO_TOT>
> > ExecStartPre=/bin/sleep
> > <
> https://opengrok-evo.juniper.net/source/s?path=/bin/sleep=EVO_TOT>
> > 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.
>
> Have you called Subscribe() on the manager object? Unless there's at
> least one client doing that (which hasn't dsiconnected yet) these
> messages are not necessarily generated.
>
> Also, which systemd version is this? There have been some bugfixes in
> this area in the past, hence make sure to run a current version of systemd.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>


-- 
thanks
Ashitha
___
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

[Daniel Tihelka via systemd-devel]

Hello,
OK, thanks for the clarification.

I was afraid that the situation is like you have described. Still it
surprises me that even the sshfs case cannot be handled by user
instance of systemd ...

Do you have any information that the kernel is going to open autofs
for unpriv clients?
Or, could it be a way to write a d-bus capable daemon (or use/extend
udisks or systemd capabilities?) which would handle the mounts for a
particular user, i.e. a user would provide remote host+fs
type+username+passwd+required mount point+access permissions and the
daemon would mount it then for the user as required. Or has this way a
security flow I don't see?

Thanks,
DT

On Mon, Feb 11, 2019 at 6:27 PM Lennart Poettering
 wrote:
>
> 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/

[Umut Tezduyar Lindskog]

Also checkout systemd generators
(https://www.freedesktop.org/software/systemd/man/systemd.generator.html).
A generator can overlay the /etc and generators should run before
systemd starts scanning the unit files.

Umut

On Mon, Feb 11, 2019 at 10:07 PM Matt Schuckmann
 wrote:
>
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Delegate= on slice before v237

[Lennart Poettering]

On Mo, 11.02.19 16:39, Filipe Brandenburger (filbran...@google.com) wrote:

> Hi Lennart,

heya!

> Before systemd v237 (when Delegate= was no longer allowed on slice
> units)... Did setting Delegate=yes on a slice have *any* effect at all?
>
> Or did it just do nothing (and a slice with Delegate=no or no setting
> behave just the same)?
>
> Reason I ask is: I want to scrap this code
> 
> in libcontainer that tries to detect whether Delegate= is accepted in a
> slice unit. (I'll just default it to false, never try it.)
>
> I'd like to be able to say that Delegate=yes never really did anything at
> all on slice units... So I'm trying to confirm that is really the case
> before stating it.

So, it wasn't supposed to do anything, and what it does differs on
cgroupsv2 and cgroupsv1. The fact it wasn't refused outright was an
accident, and because it was one I am not entirely sure what the
precise effect of allowing it was. However, I am pretty sure it at
least had two effects:

1. it would turn on all controllers for the cgroup

2. it would stop systemd to ever migrating foreign processes below
   that slice, which is primarily relevant only when changing cgroup
   related props on the slice dynamically I guess.

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] Missing PropertiesChanged signal for service start

[Lennart Poettering]

On Mo, 11.02.19 19:50, systemd Mailing List 
(systemd-devel@lists.freedesktop.org) wrote:

> 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.

Have you called Subscribe() on the manager object? Unless there's at
least one client doing that (which hasn't dsiconnected yet) these
messages are not necessarily generated.

Also, which systemd version is this? There have been some bugfixes in
this area in the past, hence make sure to run a current version of systemd.

Lennart

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