Re: [systemd-devel] Locking current session programmatically

[Kirill Elagin]

Right, sorry, I was probably thinking about something different.

Speaking about marking `.Lock` non-privileged, I'd like to point out that
there is also `.Unlock` and so, by making one of them non-privileged and
the other one privileged, we kind of introduce asymmetry.
On the other hand, making `.Unlock` non-privileged may be seen as a
security issue, at least the KDE guys think that. I've already tried to
start a discussion about `Lock/Unlock` used by users here:
http://lists.freedesktop.org/archives/systemd-devel/2014-April/018410.html.


--
Кирилл Елагин


On Sun, Jun 29, 2014 at 2:04 PM, Mantas Mikulėnas  wrote:

> A session manager is *not necessary* for this; the screensaver or
> screenlocker itself could easily listen to the relevant DBus signals (e.g.
> cinnamon-screensaver does this). See also: xss-lock, systemd-lock-handler.
>
> --
> Mantas Mikulėnas 
> // sent from phone
> On Jun 29, 2014 1:02 PM, "Kirill Elagin"  wrote:
>
>> If you don't have a DE you don't have a session manager either, so
>> systemd-logind can't help you anyway.
>> Indeed, you should just run your screenlocker.
>>
>>
>> --
>> Кирилл Елагин
>>
>>
>> On Sun, Jun 29, 2014 at 9:57 AM, Ivan Shapovalov 
>> wrote:
>>
>>> >> 27 июня 2014 г., в 21:54, Lennart Poettering 
>>> написал(а):
>>> >>
>>> >> On Fri, 27.06.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote:
>>> >>
>>> >> I want to lock my current session using a command-line tool (or a
>>> D-Bus call).
>>> >>
>>> >> The only apparent way to do this is `loginctl lock-session
>>> $XDG_SESSION_ID`.
>>> >> However, this results in an "Access denied" reply, which is somewhat
>>> strange
>>> >> (I expect to be able to lock my own session).
>>> >>
>>> >> Is this by design or a bug?
>>> >
>>> > Neither. Just missing functionality. I added this to the TODO list now.
>>> >
>>> >> In either case, is it possible to lock the current
>>> >> session?
>>> >
>>> > Well, not with logind, no. But you should be able to do it with
>>> GNOME's APIs.
>>> >
>>> > Lennart
>>> >
>>> > --
>>> > Lennart Poettering, Red Hat
>>>
>>> I've got a DE-less setup (a freestanding window manager). Should I just
>>> invoke whatever tool I use for screenlocking (i3lock in my case)?
>>>
>>> --
>>> Ivan Shapovalov / intelfx /
>>>
>>> (Sent from a phone. Havoc may be wreaked on the formatting.)
>>> ___
>>> systemd-devel mailing list
>>> systemd-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Locking current session programmatically

[Kirill Elagin]

If you don't have a DE you don't have a session manager either, so
systemd-logind can't help you anyway.
Indeed, you should just run your screenlocker.


--
Кирилл Елагин


On Sun, Jun 29, 2014 at 9:57 AM, Ivan Shapovalov 
wrote:

> >> 27 июня 2014 г., в 21:54, Lennart Poettering 
> написал(а):
> >>
> >> On Fri, 27.06.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> >>
> >> I want to lock my current session using a command-line tool (or a D-Bus
> call).
> >>
> >> The only apparent way to do this is `loginctl lock-session
> $XDG_SESSION_ID`.
> >> However, this results in an "Access denied" reply, which is somewhat
> strange
> >> (I expect to be able to lock my own session).
> >>
> >> Is this by design or a bug?
> >
> > Neither. Just missing functionality. I added this to the TODO list now.
> >
> >> In either case, is it possible to lock the current
> >> session?
> >
> > Well, not with logind, no. But you should be able to do it with GNOME's
> APIs.
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Red Hat
>
> I've got a DE-less setup (a freestanding window manager). Should I just
> invoke whatever tool I use for screenlocking (i3lock in my case)?
>
> --
> Ivan Shapovalov / intelfx /
>
> (Sent from a phone. Havoc may be wreaked on the formatting.)
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to conditional reload service

[Kirill Elagin]

`systemctl reload-or-restart`?


--
Кирилл Елагин


On Sun, Jun 22, 2014 at 10:05 PM, Vasiliy Tolstov 
wrote:

> Hi. I have a problem - bird service.
> [Unit]
> Description=BIRD routing daemon ipv6 version
> After=network.target
>
> [Service]
> ExecStart=/usr/bin/bird6 -f -u bird -g bird
> ExecReload=/usr/bin/birdc6 configure
> ExecStop=/usr/bin/birdc6 down
>
> [Install]
> WantedBy=multi-user.target
>
> In this case reload only works when service is runing. But if i need
> that reload acts as restart if service not running?
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
> jabber: v...@selfip.ru
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd not initializing

[Kirill Elagin]

Please, try to ssh into the system when it is stuck and show us the log
from `journalctl -b`.

Or, alternatively, do as earlier, reboot the stuck system, boot with
init=/bin/sh and get the log with `journalctl -b -1`.
But ssh is preferred as it will let you troubleshoot the issue further
interactively.
On Jun 17, 2014 1:23 PM, "Jay D Bhatt"  wrote:

> Hi,
>
> From the log I attached previously, I think is log statement saying as
> below:
>
>  Starting Login Service...
>
> But then , it gets stuck at
>
> [  OK  ] Reached target Login Prompts.
>
> So, I think there would be problem with systemd-login.service file for so?
> Can anybody point, why there is no move ahead after this statement?
>
> Thanks,
> Jay
>
>
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or mailad...@igate.com  mailad...@igate.com>. IGATE does not enter into any agreement with any
> party by e-mail. Any views expressed by an individual do not necessarily
> reflect the view of IGATE. IGATE is not responsible for the consequences of
> any actions taken on the basis of information provided, through this email.
> The contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While IGATE has taken every
> reasonable precaution to minimise this risk, we cannot accept liability for
> any damage which you sustain as a result of softwar
>  e viruses. You should carry out your own virus checks before opening an
> attachment. To know more about IGATE please visit www.igate.com <
> http://www.igate.com>.
>
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd not initializing

[Kirill Elagin]

First of all the log is somewhat deformed. You could probably add
`--no-pager` or something like this to see the full lines.

It's not clear why mounting /tmp fails as I can't see any errors about
failing to mount /run and as far as I can tell there should be an error
logged in case it fails as /run is MNT_FATAL.

Also I've noticed:

~~
Dec 31 18:43:16 192.168.149.68 systemd[1]: Listening on sshd.socket.
~~

so it looks like if you have difficulties with consoles you might try to
ssh in.


--
Кирилл Елагин


On Fri, Jun 13, 2014 at 1:18 PM, Jay D Bhatt  wrote:

> Sorry, Forgot to send log.
>
> I got the previous log  by command use `journalctl --boot -1`
>
> Please find the log attached. This time the system stopped prior to
> previous run.
>
> This time it stopped at :
>
> [  OK  ] Started D-Bus System Message Bus.
>  Starting Authorization Manager...
>
> Thanks,
> Jay
>
>
>
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or mailad...@igate.com  mailad...@igate.com>. IGATE does not enter into any agreement with any
> party by e-mail. Any views expressed by an individual do not necessarily
> reflect the view of IGATE. IGATE is not responsible for the consequences of
> any actions taken on the basis of information provided, through this email.
> The contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While IGATE has taken every
> reasonable precaution to minimise this risk, we cannot accept liability for
> any damage which you sustain as a result of software viruses. You should
> carry out your own virus checks before opening an attachment. To know more
> about IGATE please visit www.igate.com .
>
> 
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd not initializing

[Kirill Elagin]

No it's definitely not a blocker.

You forgot to attach a log your previous message.


--
Кирилл Елагин


On Fri, Jun 13, 2014 at 1:09 PM, Jay D Bhatt  wrote:

>  Hi Kirill,
>
>
>
> I got to enable CONFIG_FANOTIFY in kernel, but I think this will not be
> high priority or blocking thing. Is it blocking thing?
>
>
>
> Thanks,
>
> Jay
>
>
>
>
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or mailad...@igate.com. IGATE does not enter
> into any agreement with any party by e-mail. Any views expressed by an
> individual do not necessarily reflect the view of IGATE. IGATE is not
> responsible for the consequences of any actions taken on the basis of
> information provided, through this email. The contents of an attachment to
> this e-mail may contain software viruses, which could damage your own
> computer system. While IGATE has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should carry out your own
> virus checks before opening an attachment. To know more about IGATE please
> visit www.igate.com.
>
> 
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd not initializing

[Kirill Elagin]

On Fri, Jun 13, 2014 at 11:01 AM, Kirill Elagin  wrote:

> I guess it was `Failed to _g_et boot id` and it its about
> `/proc/sys/kernel/random/boot_id`.
> Is that kernel < 2.3.15 or what?
>

Oh, never mind, that's probably just because `/proc` is not mounted when
`init=/bin/sh`.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd not initializing

[Kirill Elagin]

I'm sorry to cut in but that's too interesting to keep just observing.

I guess it was `Failed to _g_et boot id` and it its about
`/proc/sys/kernel/random/boot_id`.
Is that kernel < 2.3.15 or what?

{- offtopic

~~~
systemd-readahead[1486]: Failed to create fanotify object: Function not
implemented
~~~

Shouldn't readme mention CONFIG_FANOTIFY?
-}


--
Кирилл Елагин


On Fri, Jun 13, 2014 at 10:31 AM, Jay D Bhatt  wrote:

> I logged in shell script using init=/bin/sh and executed journalctl
> --boot, It says "No journal files were found. Failed to set boot id: No
> such file or directory" .
>
> I don't get login prompt when I use init=/sbin/init, so tried with
> init=/bin/sh. Is it correct?
>
> Thanks,
> Jay
>
>
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or mailad...@igate.com  mailad...@igate.com>. IGATE does not enter into any agreement with any
> party by e-mail. Any views expressed by an individual do not necessarily
> reflect the view of IGATE. IGATE is not responsible for the consequences of
> any actions taken on the basis of information provided, through this email.
> The contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While IGATE has taken every
> reasonable precaution to minimise this risk, we cannot accept liability for
> any damage which you sustain as a result of softwar
>  e viruses. You should carry out your own virus checks before opening an
> attachment. To know more about IGATE please visit www.igate.com <
> http://www.igate.com>.
>
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

[Kirill Elagin]

You're welcome.

Please, tell the PMS guys to add this to the spec and ask the Paludis guys
to implement this as well.


--
Кирилл Елагин


On Thu, Jun 12, 2014 at 1:33 AM, Mike Gilbert  wrote:

> On Wed, Jun 11, 2014 at 4:56 PM, Mike Gilbert  wrote:
> > On Wed, Jun 11, 2014 at 12:15 PM, Kirill Elagin 
> wrote:
> >> On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert 
> wrote:
> >>>
> >>> On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering
> >>>  wrote:
> >>> > On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote:
> >>> >
> >>> >> > Symlinks should probably just be considered different type of
> file,
> >>> >> > that
> >>> >> > have a contents and stuff. The contents is usually a file name,
> and
> >>> >> > there's a size limit, but other than that it's just a magic kind
> of
> >>> >> > file, where the symlink destination is the conents. That's how git
> >>> >> > handles this, for example.
> >>> >> >
> >>> >> > I have the suspicion that this is really something to fix in your
> >>> >> > package manager. It should learn to handle symlink upgrades the
> same
> >>> >> > way
> >>> >> > as configuration file upgrades
> >>> >>
> >>> >> The problem with installing these symlinks as part of a package is
> >>> >> that the user may have removed them from /etc/systemd using
> systemctl
> >>> >> disable. The next time they install systemd, the package puts the
> >>> >> symlinks right back.
> >>> >
> >>> > Again, that's exactly what happens for configuration files too if you
> >>> > use automake: on "make install" they are replaced by the original,
> >>> > upstream versions. Why is recreating the symlinks bad, if overriding
> the
> >>> > config files isn't?
> >>> >
> >>>
> >>> People don't generally remove config files; they just make changes.
> >>>
> >>> On the other hand, removing the symlinks would be a very typical
> >>> action due to the way systemctl disable works. There is some ambiguity
> >>> as to what a missing symlink means: did the sysadmin remove it, or did
> >>> it never exist in the first place?
> >>
> >>
> >> But there is `equery f`, so it shouldn't be too hard to figure this out,
> >> right?
> >>
> >
> > It is one thing to query the package database with a tool designed for
> > users. It is quite another to modify our package manager to use the
> > information in an intelligent way. Patches are welcome, as always.
>
> Actually, I think I have talked myself into working on such an
> enhancement myself. Thanks.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to Restrict device in systemd?

[Kirill Elagin]

By the way, reading throw the NEWS I thought you might be interested in
`InaccessibleDirectories=/` or something like that


--
Кирилл Елагин


On Wed, Jun 4, 2014 at 1:18 PM, Mohit Agrawal  wrote:

> Hi,
>
> Thanks to share the example of unit file,now query is resolved.
>
>
> Regards
> Mohit Agrawal
>
> - Original Message -
> From: "Kirill Elagin" 
> To: "Mohit Agrawal" 
> Cc: "systemd Mailing List" 
> Sent: Wednesday, June 4, 2014 1:03:47 PM
> Subject: Re: [systemd-devel] How to Restrict device in systemd?
>
> Here is a proof that this kind of limiting for devices actually works. This
> service is trying to read the first byte of `/dev/sda1` but is allowed to
> access `/dev/zero` only:
>
> ~~~
> [Unit]
> Description=test
> [Service]
> Type=oneshot
> ExecStart=/bin/head /dev/sda1 -c 1
> DeviceAllow=/dev/zero r
> DevicePolicy=strict
> ~~
>
> ~
> # systemctl start bar.service
> Job for bar.service failed. See 'systemctl status bar.service' and
> 'journalctl -xn' for details.
>
> # systemctl status bar.service
> <...>
> Jun 04 11:30:53 kirNote head[26237]: /bin/head: cannot open ‘/dev/sda1’ for
> reading: Operation not permitted
> Jun 04 11:30:53 kirNote systemd[1]: bar.service: main process exited,
> code=exited, status=1/FAILURE
> Jun 04 11:30:53 kirNote systemd[1]: Failed to start test.
> Jun 04 11:30:53 kirNote systemd[1]: Unit bar.service entered failed state.
> 
>
>
>
> --
> Кирилл Елагин
>
>
> On Wed, Jun 4, 2014 at 11:29 AM, Kirill Elagin 
> wrote:
>
> > Well, first of all, your `DeviceAllow` syntax is still wrong. “Takes two
> > space-separated strings: a device node path (such as /dev/null) followed
> by
> > a combination of r, w, m”.
> >
> > But that's not the main issue here. The main issue here is that
> > devices.allow and devices.deny control access to _devices_.
> > Your own user doesn't have write access to `/dev/sda`, but, somehow, you
> > still can create files in your home directory, right? That's because file
> > creation (and actually all the filessytem access) is done through kernel
> > interfaces, not by reading/writing devices nodes directly (that would be
> > kind insecure, right?).
> >
> > I can't come up with a proper solution to limit FS access if your process
> > will be running as root.
> >
> >
> > --
> > Кирилл Елагин
> >
> >
> > On Wed, Jun 4, 2014 at 11:16 AM, Mohit Agrawal 
> > wrote:
> >
> >> Hi Kirill,
> >>
> >>
> >> Thanks for your valuable reply.As per man page DeviceAllow(Use to
> control
> >> access to specific device nodes by the executed process,This also
> controls
> >> the devices.allow and devices.deny both My query is how it is controls
> the
> >> device.deny),I am assuming after update DevicePolicy to strict means
> only
> >> process can be used allowed type of devices no other devices but after
> add
> >> the DevicePolicy also it is trying to create the file on /root/file_1.
> >>
> >> DeviceAllow=
> >>Control access to specific device nodes by the executed
> >>processes. Takes two space-separated strings: a device node
> >> path
> >>(such as /dev/null) followed by a combination of r, w, m to
> >>control reading, writing, or creation of the specific device
> >> node
> >>by the unit (mknod), respectively. This controls the
> >>"devices.allow" and "devices.deny" control group attributes.
> >> For
> >>details about these control group attributes, see
> >> devices.txt[4].
> >>
> >>DevicePolicy=auto|closed|strict
> >>Control the policy for allowing device access:
> >>
> >>strict
> >>means to only allow types of access that are explicitly
> >>specified.
> >>
> >> [Unit]
> >> Description=mydevblock
> >> [Service]
> >> DeviceAllow=/dev/zero
> >> DevicePolicy=strict
> >> ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=400
> >> Restart=always
> >> [Install]
> >> WantedBy=multi-user.target
> >>
> >> I believe it should restrict to create the file .
> >>
> >>
> >> Regards
> >> Mohit Agrawal
> >>
> >>
> >>
> >> - Original M

Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

[Kirill Elagin]

On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert  wrote:

> On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering
>  wrote:
> > On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote:
> >
> >> > Symlinks should probably just be considered different type of file,
> that
> >> > have a contents and stuff. The contents is usually a file name, and
> >> > there's a size limit, but other than that it's just a magic kind of
> >> > file, where the symlink destination is the conents. That's how git
> >> > handles this, for example.
> >> >
> >> > I have the suspicion that this is really something to fix in your
> >> > package manager. It should learn to handle symlink upgrades the same
> way
> >> > as configuration file upgrades
> >>
> >> The problem with installing these symlinks as part of a package is
> >> that the user may have removed them from /etc/systemd using systemctl
> >> disable. The next time they install systemd, the package puts the
> >> symlinks right back.
> >
> > Again, that's exactly what happens for configuration files too if you
> > use automake: on "make install" they are replaced by the original,
> > upstream versions. Why is recreating the symlinks bad, if overriding the
> > config files isn't?
> >
>
> People don't generally remove config files; they just make changes.
>
> On the other hand, removing the symlinks would be a very typical
> action due to the way systemctl disable works. There is some ambiguity
> as to what a missing symlink means: did the sysadmin remove it, or did
> it never exist in the first place?
>

But there is `equery f`, so it shouldn't be too hard to figure this out,
right?


>
> If systemctl disable would do something like create a symlink to
> /dev/null, that would be easier to detect.
>
> I suppose we should implement something like Debian's conffiles to
> protect file removals, but that's probably not going to be a very high
> priority given the small number of packages for which it really
> matters.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-netword]

[Kirill Elagin]

`failed` is a state of a unit and as such it is documented in `systemd` man
page.
I'm not sure if `systemd` man page fits into your definition of
“associated”.


   Units may be "active" (meaning started,
   bound, plugged in, ..., depending on the unit type, see below), or
   "inactive" (meaning stopped, unbound, unplugged, ...), as well as in
   the process of being activated or deactivated, i.e. between the two
   states (these states are called "activating", "deactivating"). A
   special "failed" state is available as well, which is very similar to
   "inactive" and is entered when the service failed in some way
(process
   returned error code on exit, or crashed, or an operation timed out).
If
   this state is entered, the cause will be logged, for later reference.
~~~


--
Кирилл Елагин


On Sat, Jun 7, 2014 at 11:57 PM, Unknown 
wrote:

> Hello. It is said in the man systemd-netword-wait-online.service:
>
> >systemd-networkd-wait-online is a one-shot system service that waits
> >for the network to be configured. By default, it will wait for all
> >links it is aware of and which are managed by
> >systemd-networkd.service(8) to be fully configured or failed, and for
> >at least one link to gain a carrier.
>
> What exactly mean "configured or failed", in this context ?
> If i have two interface managed by systemd-networkd, one which is up
> and fully configured and one another that is not (like, an ethernet
> interface with no cable plugged in), does that mean this other one is
> "failed" ? In which state is he ?
>
> I think (maybe wrongly) this should be precised somewhere, because I
> searched for "fail" in the associated man pages, and found nothing.
>
> Thank you.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to Restrict device in systemd?

[Kirill Elagin]

Here is a proof that this kind of limiting for devices actually works. This
service is trying to read the first byte of `/dev/sda1` but is allowed to
access `/dev/zero` only:

~~~
[Unit]
Description=test
[Service]
Type=oneshot
ExecStart=/bin/head /dev/sda1 -c 1
DeviceAllow=/dev/zero r
DevicePolicy=strict
~~

~
# systemctl start bar.service
Job for bar.service failed. See 'systemctl status bar.service' and
'journalctl -xn' for details.

# systemctl status bar.service
<...>
Jun 04 11:30:53 kirNote head[26237]: /bin/head: cannot open ‘/dev/sda1’ for
reading: Operation not permitted
Jun 04 11:30:53 kirNote systemd[1]: bar.service: main process exited,
code=exited, status=1/FAILURE
Jun 04 11:30:53 kirNote systemd[1]: Failed to start test.
Jun 04 11:30:53 kirNote systemd[1]: Unit bar.service entered failed state.




--
Кирилл Елагин


On Wed, Jun 4, 2014 at 11:29 AM, Kirill Elagin  wrote:

> Well, first of all, your `DeviceAllow` syntax is still wrong. “Takes two
> space-separated strings: a device node path (such as /dev/null) followed by
> a combination of r, w, m”.
>
> But that's not the main issue here. The main issue here is that
> devices.allow and devices.deny control access to _devices_.
> Your own user doesn't have write access to `/dev/sda`, but, somehow, you
> still can create files in your home directory, right? That's because file
> creation (and actually all the filessytem access) is done through kernel
> interfaces, not by reading/writing devices nodes directly (that would be
> kind insecure, right?).
>
> I can't come up with a proper solution to limit FS access if your process
> will be running as root.
>
>
> --
> Кирилл Елагин
>
>
> On Wed, Jun 4, 2014 at 11:16 AM, Mohit Agrawal 
> wrote:
>
>> Hi Kirill,
>>
>>
>> Thanks for your valuable reply.As per man page DeviceAllow(Use to control
>> access to specific device nodes by the executed process,This also controls
>> the devices.allow and devices.deny both My query is how it is controls the
>> device.deny),I am assuming after update DevicePolicy to strict means only
>> process can be used allowed type of devices no other devices but after add
>> the DevicePolicy also it is trying to create the file on /root/file_1.
>>
>> DeviceAllow=
>>Control access to specific device nodes by the executed
>>processes. Takes two space-separated strings: a device node
>> path
>>(such as /dev/null) followed by a combination of r, w, m to
>>control reading, writing, or creation of the specific device
>> node
>>by the unit (mknod), respectively. This controls the
>>"devices.allow" and "devices.deny" control group attributes.
>> For
>>details about these control group attributes, see
>> devices.txt[4].
>>
>>DevicePolicy=auto|closed|strict
>>Control the policy for allowing device access:
>>
>>strict
>>means to only allow types of access that are explicitly
>>specified.
>>
>> [Unit]
>> Description=mydevblock
>> [Service]
>> DeviceAllow=/dev/zero
>> DevicePolicy=strict
>> ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=400
>> Restart=always
>> [Install]
>> WantedBy=multi-user.target
>>
>> I believe it should restrict to create the file .
>>
>>
>> Regards
>> Mohit Agrawal
>>
>>
>>
>> - Original Message -
>> From: "Kirill Elagin" 
>> To: "Mohit Agrawal" 
>> Cc: "systemd Mailing List" 
>> Sent: Wednesday, June 4, 2014 12:17:46 PM
>> Subject: Re: [systemd-devel] How to Restrict device in systemd?
>>
>> First of all, according to docs, `DeviceAllow` syntax is somewhat
>> different
>> from what you have.
>> Second, you might want to check `DevicePolicy`, as now your unit has
>> access
>> not only to `/dev/zero`, but also to four other devices.
>>
>> And hm, I thought, those directives control access to device nodes. Why
>> are
>> you expecting them to limit access to the filesystem?
>>
>>
>> --
>> Кирилл Елагин
>>
>>
>> On Wed, Jun 4, 2014 at 10:18 AM, Mohit Agrawal 
>> wrote:
>>
>> > Hi,
>> >
>> > I want to block the device through the systemd cgroup so I have created
>> a
>> > below unit file
>> >
>> > [Unit]
>> > Description=mydevblock
>> > [Service]
>> > DeviceAllow=/dev/zero
>&g

Re: [systemd-devel] How to Restrict device in systemd?

[Kirill Elagin]

Well, first of all, your `DeviceAllow` syntax is still wrong. “Takes two
space-separated strings: a device node path (such as /dev/null) followed by
a combination of r, w, m”.

But that's not the main issue here. The main issue here is that
devices.allow and devices.deny control access to _devices_.
Your own user doesn't have write access to `/dev/sda`, but, somehow, you
still can create files in your home directory, right? That's because file
creation (and actually all the filessytem access) is done through kernel
interfaces, not by reading/writing devices nodes directly (that would be
kind insecure, right?).

I can't come up with a proper solution to limit FS access if your process
will be running as root.


--
Кирилл Елагин


On Wed, Jun 4, 2014 at 11:16 AM, Mohit Agrawal  wrote:

> Hi Kirill,
>
>
> Thanks for your valuable reply.As per man page DeviceAllow(Use to control
> access to specific device nodes by the executed process,This also controls
> the devices.allow and devices.deny both My query is how it is controls the
> device.deny),I am assuming after update DevicePolicy to strict means only
> process can be used allowed type of devices no other devices but after add
> the DevicePolicy also it is trying to create the file on /root/file_1.
>
> DeviceAllow=
>Control access to specific device nodes by the executed
>processes. Takes two space-separated strings: a device node path
>(such as /dev/null) followed by a combination of r, w, m to
>control reading, writing, or creation of the specific device
> node
>by the unit (mknod), respectively. This controls the
>"devices.allow" and "devices.deny" control group attributes. For
>details about these control group attributes, see
> devices.txt[4].
>
>DevicePolicy=auto|closed|strict
>Control the policy for allowing device access:
>
>strict
>means to only allow types of access that are explicitly
>specified.
>
> [Unit]
> Description=mydevblock
> [Service]
> DeviceAllow=/dev/zero
> DevicePolicy=strict
> ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=400
> Restart=always
> [Install]
> WantedBy=multi-user.target
>
> I believe it should restrict to create the file .
>
>
> Regards
> Mohit Agrawal
>
>
>
> - Original Message -
> From: "Kirill Elagin" 
> To: "Mohit Agrawal" 
> Cc: "systemd Mailing List" 
> Sent: Wednesday, June 4, 2014 12:17:46 PM
> Subject: Re: [systemd-devel] How to Restrict device in systemd?
>
> First of all, according to docs, `DeviceAllow` syntax is somewhat different
> from what you have.
> Second, you might want to check `DevicePolicy`, as now your unit has access
> not only to `/dev/zero`, but also to four other devices.
>
> And hm, I thought, those directives control access to device nodes. Why are
> you expecting them to limit access to the filesystem?
>
>
> --
> Кирилл Елагин
>
>
> On Wed, Jun 4, 2014 at 10:18 AM, Mohit Agrawal 
> wrote:
>
> > Hi,
> >
> > I want to block the device through the systemd cgroup so I have created a
> > below unit file
> >
> > [Unit]
> > Description=mydevblock
> > [Service]
> > DeviceAllow=/dev/zero
> > ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=40
> > Restart=always
> > [Install]
> > WantedBy=multi-user.target
> >
> >
> > As per my understanding in this unit file I have allowed only /dev/zero
> > device so dd command should not create the file_1 successfully it should
> > give the error .
> >
> > systemctl start mydevblock.service
> >
> > Below is the status after start the service and file_1 is successfully
> > created
> >
> > [host-name ~]# systemctl status mydevblock.service
> > ● mydev.service - mydevblock
> >Loaded: loaded (/etc/systemd/system/mydev.service; disabled)
> >Active: failed (Result: start-limit) since Wed 2014-06-04 11:32:24
> IST;
> > 831ms ago
> >   Process: 27800 ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M
> > count=40 (code=exited, status=0/SUCCESS)
> >  Main PID: 27800 (code=exited, status=0/SUCCESS)
> >
> > Jun 04 11:32:24  systemd[1]: mydev.service holdoff time over,
> > scheduling restart.
> > Jun 04 11:32:24  systemd[1]: Stopping mydevblock...
> > Jun 04 11:32:24  systemd[1]: Starting mydevblock...
> > Jun 04 11:32:24  sytemd[1]: mydev.service start request
> > repeated too quickly, refusing to start.
> > Jun 04 11:32:24  systemd[1]: Failed to s

Re: [systemd-devel] How to Restrict device in systemd?

[Kirill Elagin]

First of all, according to docs, `DeviceAllow` syntax is somewhat different
from what you have.
Second, you might want to check `DevicePolicy`, as now your unit has access
not only to `/dev/zero`, but also to four other devices.

And hm, I thought, those directives control access to device nodes. Why are
you expecting them to limit access to the filesystem?


--
Кирилл Елагин


On Wed, Jun 4, 2014 at 10:18 AM, Mohit Agrawal  wrote:

> Hi,
>
> I want to block the device through the systemd cgroup so I have created a
> below unit file
>
> [Unit]
> Description=mydevblock
> [Service]
> DeviceAllow=/dev/zero
> ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=40
> Restart=always
> [Install]
> WantedBy=multi-user.target
>
>
> As per my understanding in this unit file I have allowed only /dev/zero
> device so dd command should not create the file_1 successfully it should
> give the error .
>
> systemctl start mydevblock.service
>
> Below is the status after start the service and file_1 is successfully
> created
>
> [host-name ~]# systemctl status mydevblock.service
> ● mydev.service - mydevblock
>Loaded: loaded (/etc/systemd/system/mydev.service; disabled)
>Active: failed (Result: start-limit) since Wed 2014-06-04 11:32:24 IST;
> 831ms ago
>   Process: 27800 ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M
> count=40 (code=exited, status=0/SUCCESS)
>  Main PID: 27800 (code=exited, status=0/SUCCESS)
>
> Jun 04 11:32:24  systemd[1]: mydev.service holdoff time over,
> scheduling restart.
> Jun 04 11:32:24  systemd[1]: Stopping mydevblock...
> Jun 04 11:32:24  systemd[1]: Starting mydevblock...
> Jun 04 11:32:24  sytemd[1]: mydev.service start request
> repeated too quickly, refusing to start.
> Jun 04 11:32:24  systemd[1]: Failed to start mydevblock.
> Jun 04 11:32:24  systemd[1]: Unit mydev.service entered failed
> state.
>
> [host-name> ~]# ls -lrt
> -rw-r--r--. 1 root root 41943040 Jun  4 11:32 file_1
>
>
> Can someone reply why file_1 is created successfully?
> Do anyone have idea how can i put the restriction on device?
> Appreciate your inputs on this.
>
>
> Regards
> Mohit Agrawal
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I disable rfkill1 service? I only have slot 0 and 2

[Kirill Elagin]

Might be that rfkill1 disappears after rfkill0 is switched off, if they are
related.


--
Кирилл Елагин


On Wed, May 28, 2014 at 8:43 AM, Mantas Mikulėnas  wrote:

> On May 28, 2014 3:25 AM, "Aaron Lewis"  wrote:
> >
> > Hi,
> >
> > I'm running Arch and recently upgraded system, now every time I boot I
> > see a dead service: rfkill1
> >
> >   systemd-rfkill@rfkill0.service   loaded active
> > exitedLoad/Save RF Kill Switch Status of rfkill0
> > ● systemd-rfkill@rfkill1.service   loaded failed
> > failedLoad/Save RF Kill Switch Status of rfkill1
> >   systemd-rfkill@rfkill2.service   loaded active
> > exitedLoad/Save RF Kill Switch Status of rfkill2
> >
> > I tried to run `systemctl disable systemd-rfkill@rfkill1`, but there's
> > no output after that and it wasn't disabled at all
> >
> > Any ideas?
> >
> > PS. rfkill list output
> >
> > 0: tpacpi_bluetooth_sw: Bluetooth
> > Soft blocked: yes
> > Hard blocked: no
> > 2: phy0: Wireless LAN
> > Soft blocked: no
> > Hard blocked: no
>
> It is a bit strange. The systemd-rfkill@ units are invoked by udev rules
> with the exact name from kernel, so a rfkill1 must have been there at some
> point, and disappeared very quickly afterwards? (There wouldn't be a hole
> in the numbering otherwise, too.)
>
> --
> Mantas Mikulėnas 
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

[Kirill Elagin]

>
> The container usecase alone is already the reason why I am so very sure
> I want this stuff, and that it needs to be in networkd, and just work. I
> want this fully automatic, so that we can create a hundred of veth
> tunnels, and trivially easy (simply by setting DHCPServer=yes for their
> .network file) make them automatically configured, passing the relevant
> configuration bits on.


I'm sorry to intervene, but there are other ways to configure containers
and similar stuff. I mean, systemd is great because it pioneered so
many cool things. Why can't we do something new? For example, prohibit
IPv4 for containers and VMs and require them to use IPv6 with link-local
addresses which will eliminate the need for any kind of configuration.
Pushing IPv6 forward is a good idea. But, well, if you find this
unacceptable, what's wrong with IPv4LL?

DHCP is complex (well, not _that_ complex, but still) and it's not
always required. E.g. IPv6 networks can live without DHCP by using
link-local addresses and, say, some basic NDP. It seems to me that
IPv4LL should suffice for all the “container use-cases”.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] writing service file that used some /proc/cmdline variable

[Kirill Elagin]

Deja vu ;).
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019136.html

So, yes, wrapper seems to be the way to go.


--
Кирилл Елагин


On Wed, May 21, 2014 at 10:18 PM, Vasiliy Tolstov wrote:

> 2014-05-21 21:49 GMT+04:00 Ran Benita :
> > Oops, I thought you meant a condition.  I don't know if there's a
> > a way to *use* the variables directly in the service files, but it can
> > be done easily enough with a shell-script wrapper.
>
>
> Yes, i think about wrapper, but systemd contains many useful features
> and i think that may be it already contains all that i need =)
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
> jabber: v...@selfip.ru
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence

[Kirill Elagin]

Could it be that all the boot ids are actually the same for some reason?
I had this issue in a container when systemd was reading boot_id from
`/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id
always was host's boot_id.

You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids
recorded in the journal (this must agree with `journalctl --list-boots`.
You can also add ` -o verbose` to see all the fields of records. Since you
say that the messages are actually stored in the journal, it might be
interesting to check their _BOOT_ID fields.


--
Кирилл Елагин


On Mon, May 12, 2014 at 12:30 AM, Chris Murphy wrote:

> >
> > It looks like --list-boots is broken. I have have the same problem on
> Rawhide with systemd-212-4.fc21.x86_64, which is a completely different VM.
> Here are the last three items with --list-boots
> >
> > -2 95117f702e4d43619072f87b20b2f31b Sat 2014-05-03 20:38:22 MDT—Sat
> 2014-05-03 20:47:17 MDT
> > -1 c9bf102876774c7a8748920f6135ddf6 Sat 2014-05-03 20:47:35 MDT—Sat
> 2014-05-03 20:51:55 MDT
> >  0 f92e4dda29a54b89a3455a10bbb298b2 Sat 2014-05-03 21:01:17 MDT—Sat
> 2014-05-03 21:05:24 MDT
>
> OK installed Rawhide clean today to a third VM, with a Btrfs subvolume
> "var" mounted at /var, and the problem doesn't occur. Each boot gets a new
> entry with --list-boots.
>
> The prior Rawhide and Fedora 20 meanwhile, still always have the same
> --list-boot list after each boot, stuck on May 3rd for some reason. So it
> seems something broke --list-boot in a state persistent manner with the
> journal files themselves. The data is in the journal file however, I can
> extract the prior boots with --since and --lines, it's just that -b [x] is
> useless. -b -1 takes me back over a week rather than the boot 30 minutes
> ago.
>
>
>
> Chris Murphy
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] GuessMainPID=no required to make daemon reload work

[Kirill Elagin]

I've just tested the way I described it and everything worked perfectly.
Definitely the issue is this short period of time, I'm almost sure
(didn't check the source, though) that systemd re-reads pidfile
the moment the main process terminates.

What's wrong with writing the new pid from the old proccess before
releasing the lock?


--
Кирилл Елагин


On Mon, May 5, 2014 at 12:00 PM, Gerd v. Egidy  wrote:

> Hi Кирилл,
>
> > OK, I've just re-read your message and it looks like all you need is add
> > `PIDFile` to your unit.
>
> This was the first thing I tried when writing the service file.
> Unfortunately it
> does not work, the service is declared dead and the new daemon is killed
> (unless I switch off killing, but then the state is still wrong and I can't
> stop the process in a sane way).
>
> > systemd will behave as expected: once your main process terminates it
> will
> > re-read PID
> > from this file (assuming that before dying your old process writes its
> > child's PID) and set it as MAINPID for your service.
>
> Hmm. Currently it is done like this: the old daemon releases the lock on
> the
> pidfile and terminates itself. The new daemon detects this and then writes
> it's
> own pid to the pidfile and locks it.
>
> So there is a short time where the old daemon is already dead and the new
> one
> hasn't written it's pid yet. Probably this is the problem. But I have to
> think
> about a way to get the locking stuff right as I can't easily transfer the
> lock
> over an exec.
>
> > But again, if your daemon is not writing a pidfile now, this way is not
> > “without changing the daemon itself first”.
>
> The current daemon already writes a pidfile. And to be more precise, it is
> not
> a problem to change the daemon, but I'd prefer not to introduce systemd-
> specific code or dependencies (like sd_notify) in the first step.
>
> Kind regards,
>
> Gerd
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] GuessMainPID=no required to make daemon reload work

[Kirill Elagin]

OK, I've just re-read your message and it looks like all you need is add
`PIDFile` to your unit.
systemd will behave as expected: once your main process terminates it will
re-read PID
from this file (assuming that before dying your old process writes its
child's PID) and
set it as MAINPID for your service.
`GuessMainPID` becomes useless, and will actually be ignored, as the man
says.

But again, if your daemon is not writing a pidfile now, this way is not
“without changing the daemon itself first”. I'm not sure you can make it
work
reliably otherwise.


--
Кирилл Елагин


On Mon, May 5, 2014 at 2:03 AM, Gerd v. Egidy  wrote:

> Hi Кирилл,
>
> > Have you looked into using sd_notify to update MAINPID?
>
> No, not yet. I have sd_notify on my list of things to look at in the
> future,
> but I wanted to make the service work without changing the daemon itself
> first.
>
> Thanks for the hint about this possibility.
>
> Kind regards,
>
> Gerd
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] GuessMainPID=no required to make daemon reload work

[Kirill Elagin]

Have you looked into using sd_notify to update MAINPID?


--
Кирилл Елагин


On Mon, May 5, 2014 at 1:19 AM, Gerd v. Egidy  wrote:

> Hi,
>
> I'm one of the developers of the Icinga monitoring system. We want to
> provide
> a .service file for our monitoring daemon with the next major release
> (Icinga
> 2).
>
> Due to technical reasons, the daemon can't reload it's configuration files
> within one process. So we implement reload like this:
>
> 1. daemon process detects a SIGHUP or reload request on a control channel
> 2. a new process is forked & execed with a special commandline argument
> indicating a reload
> 3. the old daemon continues it's normal work
> 4. the new process loads and checks the configuration (this can be time
> consuming)
> 5. a) on config errors the new process terminates. the old daemon detects
> the
> SIGCHLD, logs error messages and so on
> 5. b) when the config is ok the new process sends a SIGTERM to the old
> daemon
> 6. the old daemon shuts down due to the SIGTERM
> 7. the new process detects when the old daemon is gone, activates it's
> config
> and starts it's work
>
> This is much better than a regular restart:
> a) the time consuming config check is done in background
> b) service is not interrupted if the new config is invalid
>
> But this scheme seems not to work well with systemd: After reload systemd
> thinks the daemon has ended and declares the whole service "inactive
> (dead)",
> usually killing the remaining daemon.
>
> After diving into the systemd manpages and trying some options, I found
> that I
> could make it work with GuessMainPID=no:
>
> [Unit]
> Description=Icinga host/service/network monitoring system
> After=syslog.target postgresql.service mariadb.service
>
> [Service]
> Type=forking
> EnvironmentFile=/etc/sysconfig/icinga2
> ExecStart=/usr/sbin/icinga2 -c ${ICINGA2_CONFIG_FILE} -d -e
> ${ICINGA2_ERROR_LOG} -u ${ICINGA2_USER} -g ${ICINGA2_GROUP}
> ExecReload=/bin/sh -c '/bin/kill -HUP `cat
> ${ICINGA2_STATE_DIR}/run/icinga2/icinga2.pid`'
> GuessMainPID=no
>
> [Install]
> WantedBy=multi-user.target
>
> Systemd seems to successfully detect the daemon pids and some short tests
> with
> systemd-208-16.fc20.x86_64 were successful. But I'm not sure about the
> downsides of GuessMainPID=no or if there are some problems with older
> versions
> of systemd or if future changes in systemd will pose problems.
>
> Can you describe the downsides of GuessMainPID=no more specific than
> "failure
> detection and automatic restarting of a service will not work reliably"?
>
> Can you recommend a better alternative for the reload scheme outlined
> above?
>
> I'd prefer if I could tell systemd about the pidfile. Systemd should then
> either automatically detect updates of the pidfile (e.g. via inotify) or at
> least re-read it if it thinks the service has changed state.
>
> Kind regards,
>
> Gerd
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unit File: Create Folder With User Permissions

[Kirill Elagin]

That's how you do this in systemd:
http://pkgs.fedoraproject.org/cgit/couchdb.git/tree/couchdb.tmpfiles.conf
https://projects.archlinux.org/svntogit/community.git/tree/trunk/couchdb.tmpfiles?h=packages/couchdb


--
Кирилл Елагин


On Sat, May 3, 2014 at 12:03 PM, Austin Matherne
wrote:

> I switched my Gentoo install over to systemd today and pretty much
> everything worked flawlessly. The only exception was CouchDB, which lacks
> systemd support in Portage, so I'm left writing my own service file.
>
> I took a peak at the files for Fedora (
> http://pkgs.fedoraproject.org/cgit/couchdb.git/tree/couchdb.service) and
> Arch (
> https://projects.archlinux.org/svntogit/community.git/tree/trunk/couchdb.service?h=packages/couchdb)
> to get an idea of what it should look like. I copied the service from Arch,
> as it looked particularly appropriate:
>
>
> [Unit]
> Description=CouchDB Server
>
> [Service]
> User=couchdb
> Type=forking
> PermissionsStartOnly=true
> ExecStart=/usr/bin/couchdb -b -o /dev/null -e /dev/null
> ExecStop=/usr/bin/couchdb -d
>
> [Install]
> WantedBy=multi-user.target
>
>
>
> However, there's a problem with this implementation. The original Gentoo
> init script created the folder /var/run/couchdb with the correct
> permissions for user couchdb at runtime using a helper
> function (checkpath). How can I do this with a systemd service?
>
> The original Gentoo init (
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/couchdb/files/couchdb.init-4?view=markup)
> and config (
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/couchdb/files/couchdb.conf-2?view=markup)
> files for reference.
>
> Any help with this would be greatly appreciated.
>
> Thanks,
> Austin
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized

[Kirill Elagin]

On Apr 30, 2014 12:23 PM, "Tom Gundersen"  wrote:
>
>
> On 30 Apr 2014 09:21, "Florian Weimer"  wrote:
> > I don't know if we can change /dev/urandom to block because that
doesn't look very backwards-compatible to me.
>
> I have seen Ted Ts'o write about wanting this, but I don't know much
more. Alternatively the kernel could send us an event when it is ready, and
we can have a service waiting for this, which other services can order
against. Simply blocking in the kernel would be simpler though, if we can
pull it off without breaking things...

Things that will break after implementing this are broken already anyway.
Getting randomness before the generator is properly initialized makes no
sense.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl --since today --follow weirdness

[Kirill Elagin]

On Wed, Apr 23, 2014 at 10:16 PM, Lennart Poettering  wrote:

> What actually happens is that the output will show you everything from
> today, and when it is done with that continue with a live output.
>

Not exactly. You don't get _everything_ form to day, you get just arg_lines
lines.
And you get the rest from today when something new is added to log.
This happens because `--follow` sets args_lines to 10 and once n_shown is 10
we pause waiting for more lines to come, and once they come we output
everything in bulk.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl --since today --follow weirdness

[Kirill Elagin]

I've checked the code, and the issue is, basically, that `--since` and
skipping to the end with `--follow` are in a way “mutually exclusive”, that
is,
they are handled in a single `if … else if …` statement, so, because
`--since` is processed first, we don't skip to head.
But since `--follow` sets arg_lines to 10, we still get just 10 lines of
output. And then the rest.


--
Кирилл Елагин


On Wed, Apr 23, 2014 at 9:53 PM, Kirill Elagin  wrote:

> Yeah, I see this with systemd 212.
>
> And let me clarify a little bit: this delay after showing first 10 lines
> is not a result of looking up for something;
> Following lines appear as soon as there is something new in the log (that
> is, actually what `-f` does).
> So, here is what I see:
>
> I type `journalctl --since today -f`.
> First 10 lines from today appear.
> As soon as something is written to log (e.g. I simulate this by
> deliberately failing a `sudo` authentication)
> all the remaining lines from today (including the new ones, of course)
> appear.
>
> That's clearly a bug.
>
>
> --
> Кирилл Елагин
>
>
> On Wed, Apr 23, 2014 at 8:05 PM, Mantas Mikulėnas wrote:
>
>> On Wed, Apr 23, 2014 at 6:12 PM, Colin Guthrie 
>> wrote:
>> > What appears to happen instead is that you get the first 10 lines from
>> > the day (i.e. after midnight) and then *all* lines from today following
>> > that after a small delay (likely not a deliberate delay - just whatever
>> > overhead it takes to lookup and output the data)
>>
>> strace shows that it isn't looking up any data; it's actually waiting
>> for inotify events for the --follow mode. Seems odd.
>>
>> --
>> Mantas Mikulėnas 
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl --since today --follow weirdness

[Kirill Elagin]

Yeah, I see this with systemd 212.

And let me clarify a little bit: this delay after showing first 10 lines is
not a result of looking up for something;
Following lines appear as soon as there is something new in the log (that
is, actually what `-f` does).
So, here is what I see:

I type `journalctl --since today -f`.
First 10 lines from today appear.
As soon as something is written to log (e.g. I simulate this by
deliberately failing a `sudo` authentication)
all the remaining lines from today (including the new ones, of course)
appear.

That's clearly a bug.


--
Кирилл Елагин


On Wed, Apr 23, 2014 at 8:05 PM, Mantas Mikulėnas  wrote:

> On Wed, Apr 23, 2014 at 6:12 PM, Colin Guthrie 
> wrote:
> > What appears to happen instead is that you get the first 10 lines from
> > the day (i.e. after midnight) and then *all* lines from today following
> > that after a small delay (likely not a deliberate delay - just whatever
> > overhead it takes to lookup and output the data)
>
> strace shows that it isn't looking up any data; it's actually waiting
> for inotify events for the --follow mode. Seems odd.
>
> --
> Mantas Mikulėnas 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unable to override systemd-udevd.service

[Kirill Elagin]

While playing with this I've also noticed that systemd treats symlinks in a
bit
weird way: looks like if it sees a symlink it dereferences it, but not all
the symlinks
in the path. Here is an example:

# systemctl show systemd-udevd.service -p FragmentPath
FragmentPath=/usr/lib64/systemd/system/systemd-udevd.service
# ln -s /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system
# systemctl daemon-reload
# systemctl show systemd-udevd.service -p FragmentPath
FragmentPath=/usr/lib/systemd/system/systemd-udevd.service
# readlink -f /etc/systemd/system/systemd-udevd.service
/usr/lib64/systemd/system/systemd-udevd.service

I feel that I'm interested in the _reason_ why this unit is loaded, that
is, I guess,
I'd like to see `/etc/systemd/system/system-udevd.service` in this case, as
it
_explains why_ systemd loaded this unit.
But what I see is `/usr/lib/systemd/system/systemd-udevd.service` which is
totally unhelpful as it is neither the path that systemd used to discover
the unit,
nor the actual path to the unit file (which is `/usr/lib64/…`).
(Here, on Gentoo, `/usr/lib` is a symlink to `/usr/lib64`.)

Probably, somehow using this and the fact that if `cp`'s target is a
symlink,
then the symlink's target will be overwritten with the symlink left where
it was,
it is possible to reproduce the issue.


--
Кирилл Елагин


On Wed, Apr 23, 2014 at 8:43 AM, Lennart Poettering
wrote:

> On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote:
>
> > linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath
> > FragmentPath=/usr/lib/systemd/system/systemd-udevd.service
> > linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service
> /etc/systemd/system
> > linux-qbc6:~ # systemctl daemon-reload
> > linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service
> /etc/systemd/system
> > linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath
> > FragmentPath=/usr/lib/systemd/system/systemd-udevd.service
> > linux-qbc6:~ # exit
> >
> > >From non-exhaustive testing it appears to be the only unit showing this
> > property. Enabling systemd debug does not add any useful information
> > (no output about unit discovery). Any way to debug it?
> >
> > The version is systemd-208-19.1.x86_64 from openSUSE.
>
> Hmm, that's weird. Is /etc on some weird mount point or so?
>
> It might be interesting to run "strace -o log -e open -p 1" and then
> trigger a
> reload, and then look at the generate log file "log". It should show you
> where systemd is looking for the udev service file, and might contain a
> hint, why it skips the file in /etc?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Two git trees

[Kirill Elagin]

The description of repo on GitHub says “Mirror of git://
anongit.freedesktop.org/systemd/systemd”.
That is, it's a mirror. I don't know how exactly it is synchronised, but,
since it is a mirror,
it might be out of date sometimes.


--
Кирилл Елагин


On Tue, Apr 8, 2014 at 10:52 AM, Kevin Wilson  wrote:

> Hello,
>
> Why are there two git trees:
> one in
> git://anongit.freedesktop.org/systemd/systemd
>  and the second in
> https://github.com/systemd/systemd.git
> It seems to me that the first one is the primary one, and there
> are cases when the second tree is not yet synchronized with the
> first one (which might be confusing)
>
> Regards,
> Kevin
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power

[Kirill Elagin]

On Thu, Apr 3, 2014 at 11:51 PM, Leonid Isaev  wrote:

> On a battery-powered system, they are most likely clean due to small
> uptime.


I can't agree.
Nowadays battery-powered systems tend to have huge uptimes
due to being mostly suspended and rarely powered-off/rebooted.

Anyway, I think Tomasz is right, impact here is hardly measurable, and
those, who
worry about those three rm's are free to override the unit file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Proper use of the Session.Unlock method call

[Kirill Elagin]

Hi,

There are plenty people who have some kind of automatic session unlocking
set up.
Examples are: BT phone proximity, USB-drive being plugged in, etc.
This is normally done via DBus `ScreenSaver.SetActive(false)` call, but
this interface is not
well-documented and, actually, it seems that this call is intended only for
screen saver disabling
and is not meant for session unlocking.

This is exactly the way the guys from KDE decided to interpret the
interface:
they take any possibility to unlock a session without entering the user's
password to be a bug.[1]
When presented with a number of convincing arguments in favour of some kind
of auto-unlock
functionality, their answer now is “KDE session manager is going to respect
logind's Lock/Unlock
signals, so do your unlocking stuff through logind”.

So, my question is this: what is the intended use of the `Session.Unlock`
call, is it acceptable to employ this method to achieve this kind of
auto-unlocking functionality?

Here is how I see it:
* User attaches his USB-drive.
* Special udev invokes a helper.
* The helper looks inside the drive and determines the owner.
* Checks the owner configuration, performs the drive authentication.
* If everything is fine, it enumerates all the sessions of this user
(proper multi-session!)
* and unlocks them.

The issue here is that the `Session.Unlock` method is privileged, so I'm
not sure yet
how to go with that. In case of udev everything is OK as it's running as
root, but
this is not always the case. So, `pkexec`? Or maybe something completely
different?


  [1]: https://bugs.kde.org/show_bug.cgi?id=314989

--
Кирилл Елагин
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel