Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

2017-03-20 Thread Mantas Mikulėnas 
First thought: Even without the exit code or anything, it's going to be
-EBUSY like 99.999% of the time. Not much else can fail during umount.

And ”Filesystem is busy" would perfectly fit the earlier error message
which you overlooked:

"Process 304 (plymouthd) has been marked to be excluded from killing.
It is running from the root file system, and thus likely to block
re-mounting of the root file system to read-only."

So you have a process holding / open (Plymouth is the boot splash screen
app) and the kernel doesn't allow it to be umounted due to that.

On Tue, Mar 21, 2017, 05:25 Chris Murphy  wrote:

> Any thoughts on this?
>
> I've followed these instructions:
> https://freedesktop.org/wiki/Software/systemd/Debugging/
> Shutdown Completes Eventually
>
> However, no additional information is being logged that gives any
> answer to why there are three remount ro attempts, and why they aren't
> succeeding.
>
> https://github.com/systemd/systemd/blob/master/src/core/umount.c
> line 409
>
> This suggests three ro attempts shouldn't happen. And then 413 says
> that / won't actually get umounted, reboot happens leaving it ro
> mounted. So the "All filesystems unmounted." doesn't tell us anything;
> but it does seem like there should be a way to expose exit code for
> umount. I'm just not sure how to do it, and if that means compiling
> systemd myself.
>
> --
> Chris Murphy
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

2017-03-20 Thread Chris Murphy 
Any thoughts on this?

I've followed these instructions:
https://freedesktop.org/wiki/Software/systemd/Debugging/
Shutdown Completes Eventually

However, no additional information is being logged that gives any
answer to why there are three remount ro attempts, and why they aren't
succeeding.

https://github.com/systemd/systemd/blob/master/src/core/umount.c
line 409

This suggests three ro attempts shouldn't happen. And then 413 says
that / won't actually get umounted, reboot happens leaving it ro
mounted. So the "All filesystems unmounted." doesn't tell us anything;
but it does seem like there should be a way to expose exit code for
umount. I'm just not sure how to do it, and if that means compiling
systemd myself.

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

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Stanislav Angelovič 
Hi Jan,

thanks for quick response. Instead of sd_bus_process(), we could perhaps
use sd_bus_flush() after creating the connection, as that one actually
processes the requests until the connection changes state to 'running'. I
tried this and it helped.

Regarding polling, I understand, but I fear this way we could get race
condition on the connection instance, since we'd have a thread doing the
polling and processing in a loop on the connection, and some other thread
(say handling the UI, or an external system event, or incoming DBus call
from another connection or whatever else) issuing a DBus call on the same
connection. I think the connection instance is not thread-safe, as once I
experienced such data race related problems. Maybe there is another way of
doing that? One that comes to my mind is having just one single thread
handling the connection and communication through it, but then it would
have to poll on other fd's as well, to be able to communicate with other
threads, for example to get DBus call request from the UI thread and
perform it on the connection. This involves asynchronous programming
paradigm for quite a simple thing, IMHO. What do you think?

Thank you,

Stanislav.


On Mon, Mar 20, 2017 at 5:19 PM, Jan Alexander Steffens <
jan.steff...@gmail.com> wrote:

> On Mon, Mar 20, 2017, 17:14 Jan Alexander Steffens 
> wrote:
>
>>
>> You could try calling sd_bus_process(bus, NULL) in a loop while it
>> returns >0 so that the initial hello is handled.
>>
>
> Actually, never mind, this is not reliable. IIRC the initial handshake has
> multiple steps so this can return zero before everything is done. Can't get
> around polling to do this properly.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] socket / service dependency

2017-03-20 Thread Ken Bass 
I thought I followed the instructions (using Centos 7 - I believe 
systemd219) ... I am running a local news server (innd.service).


I needed to add an additional inetd style daemon for nnrpd to support 
SSL. See files below. Using the BindTo and After seems proper since I 
never want nnrpd running unless innd is already started/running. If innd 
is stopped, i want to be sure nnrpd is stopped. Initially this worked 
fine. But if I stop the innd service, and then start it again, the 
nnrpd.socket is not started. How do I handle this?


I created a drop in file for innd with a Before/Wants of nnrpd. This 
sometimes works, but normally I get 'Job innd.service/start deleted to 
break ordering cycle starting with nnrpd.socket/start'. What is the 
proper way to do this.


/etc/systemd/system/innd.d/innd.conf

[Unit]
Before=nnrpd.socket
Wants=nnrpd.socket

Files below:

/etc/systemd/system/nnrpd.socket

[Unit]
Description=nnrpd SSL socket listeners
After=syslog.target network.target
ConditionPathExists=/etc/news/inn.conf
BindsTo=innd.service
After=innd.service

[Socket]
ListenStream=563
Accept=yes

[Install]
WantedBy=multi-user.target

and

/etc/systemd/system/nnrpd@service

[Unit]
Description=nnrpd SSL server

[Service]
User=news
PermissionsStartOnly=true
ExecStart=/usr/libexec/news/nnrpd -p 563 -S
StandardInput=socket
SuccessExitStatus=1

Existing innd.service, as installed from EPEL repo,

[Unit]
Description=InterNet News Daemon
After=syslog.target network.target
ConditionPathExists=/etc/news/inn.conf

[Service]
User=news
PermissionsStartOnly=true
PIDFile=/run/news/innd.pid
Type=forking
ExecStart=/usr/libexec/news/rc.news
ExecStop=/bin/su -m  news -c '/usr/libexec/news/rc.news stop'
KillMode=control-group

[Install]


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

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Jan Alexander Steffens 
On Mon, Mar 20, 2017, 17:14 Jan Alexander Steffens 
wrote:

>
> You could try calling sd_bus_process(bus, NULL) in a loop while it returns
> >0 so that the initial hello is handled.
>

Actually, never mind, this is not reliable. IIRC the initial handshake has
multiple steps so this can return zero before everything is done. Can't get
around polling to do this properly.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Jan Alexander Steffens 
On Mon, Mar 20, 2017, 16:37 Stanislav Angelovič 
wrote:

> Hi,
>
> We use sd-bus for DBus IPC in our own applications. Some applications of
> ours cause the dbus daemon to issue "Connection has not authenticated soon
> enough, closing it" message, leading to the
> org.freedesktop.DBus.Error.Timeout error at the peer side when the
> connection is used for an IPC call.
>
> The situation is the following:
> 1. We have a DBus client application.
> 2. A connection is created using sd_bus_open_system() on application
> startup.
> 3. The connection is kept open and unused (i.e. no other sd-bus functions
> invoked on it).
> 4. After 30 seconds, we get the above-mentioned authentication timeout
> message from the dbus daemon, and any attempt to issue calls against a
> service via this connection fails with immediate timeout error as mentioned
> above. However, if the call is made before the 30 seconds authentication
> timeout, the dbus daemon prints nothing and the call succeeds, just like
> any subsequent call, even if issued after 1 hour from the first one.
>
> Is that correct behavior? We would like to open dbus connections at
> application startup, and use it for communication at any time later,
> depending on user actions. Is there something we are missing?
>
> And a side suggestion: If we want to close a connection that has not been
> used for any IPC call at all, after some struggling we have realized that
> sd_bus_unref() is not enough, as there is a lingering DBus.Hello reply
> which keeps the reference count on that connection, leading to lingering
> connections. sd_bus_flush_close_unref() is needed instead. That behavior
> could be mentioned in the documentation, e.g. at
> http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html in the
> reference client implementation, to save others from pain.
>
> Thanks a lot,
>
> Stanislav.
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel


You could try calling sd_bus_process(bus, NULL) in a loop while it returns
>0 so that the initial hello is handled.

However, that only gets you past the hello. To be a good D-Bus client, you
should poll the connection and process any unexpected incoming messages.
The best approach depends on what your app and your use of sd-bus looks
like.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Stanislav Angelovič 
Hi,

We use sd-bus for DBus IPC in our own applications. Some applications of
ours cause the dbus daemon to issue "Connection has not authenticated soon
enough, closing it" message, leading to the
org.freedesktop.DBus.Error.Timeout error at the peer side when the
connection is used for an IPC call.

The situation is the following:
1. We have a DBus client application.
2. A connection is created using sd_bus_open_system() on application
startup.
3. The connection is kept open and unused (i.e. no other sd-bus functions
invoked on it).
4. After 30 seconds, we get the above-mentioned authentication timeout
message from the dbus daemon, and any attempt to issue calls against a
service via this connection fails with immediate timeout error as mentioned
above. However, if the call is made before the 30 seconds authentication
timeout, the dbus daemon prints nothing and the call succeeds, just like
any subsequent call, even if issued after 1 hour from the first one.

Is that correct behavior? We would like to open dbus connections at
application startup, and use it for communication at any time later,
depending on user actions. Is there something we are missing?

And a side suggestion: If we want to close a connection that has not been
used for any IPC call at all, after some struggling we have realized that
sd_bus_unref() is not enough, as there is a lingering DBus.Hello reply
which keeps the reference count on that connection, leading to lingering
connections. sd_bus_flush_close_unref() is needed instead. That behavior
could be mentioned in the documentation, e.g. at
http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html in the
reference client implementation, to save others from pain.

Thanks a lot,

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

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Mantas Mikulėnas 
On Mon, Mar 20, 2017 at 3:50 PM, Cristian Rodríguez <
crrodrig...@opensuse.org> wrote:

>
>
> El 20-03-2017 a las 10:26, D.S. Ljungmark escribió:
> > I find your argument to be strange.
> >
> > "The kernel has this functionality, please do not use it and rather
> > reimplement it in every piece of userspace that ever needs it, because
> > that's supposed to be more secure."
> >
> > I simply don't buy your argument here.
>
> I guess we can't please everyone.. next it will come the "systemd has
> too many library dependencies" crowd :-|


systemd already has had a dependency on libgcrypt for a long time, though.

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

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Cristian Rodríguez 


El 20-03-2017 a las 10:26, D.S. Ljungmark escribió:
> I find your argument to be strange.
> 
> "The kernel has this functionality, please do not use it and rather
> reimplement it in every piece of userspace that ever needs it, because
> that's supposed to be more secure."
> 
> I simply don't buy your argument here.

I guess we can't please everyone.. next it will come the "systemd has
too many library dependencies" crowd :-|


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

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread D.S. Ljungmark 
I find your argument to be strange.

"The kernel has this functionality, please do not use it and rather
reimplement it in every piece of userspace that ever needs it, because
that's supposed to be more secure."

I simply don't buy your argument here.

//D.S.

On Mon, Mar 20, 2017 at 8:22 AM, Eric Biggers  wrote:
> Hello,
>
> The latest systemd README and NEWS claim that the userspace interface to the
> in-kernel hash algorithms (CONFIG_CRYPTO_USER_API_HASH) is now required.
>
> I don't know how much thought was put into this decision, but I think it's a
> mistake security-wise.  AF_ALG sockets increase the kernel's attack surface by
> allowing users to instantiate and use arbitrary crypto algorithms, in
> combinations or ways which may not have been tested.  Indeed, historically 
> there
> have been a number of security vulnerabilities related to this feature, both 
> in
> the API itself and in the various crypto modules.  For this reason, I think
> security-conscious users would prefer to have this kernel feature turned off.
>
> Why exactly does systemd suddenly need this feature?  If it's really just to
> compute hashes, then please do it in userspace instead.  Unless systemd 
> *really*
> needs to support using hardware crypto accelerators, there is no need to call
> into the kernel just to compute hashes.  Or at the very least, make the
> dependency optional.
>
> Thanks!
>
> - Eric
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] nsapwned container terminal background color

2017-03-20 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, Mar 20, 2017 at 08:34:02AM +, arnaud gaboury wrote:
> > > Are you starting the container manually using systemd-nspawn in a
> > terminal
> > > emulator window?
> 
> Not really. The container is started at machine boot with
> systemd-nspawn@container.service. Then, in one urxvt terminal, I log into
> the container with :
> # machinectl login container
> 
> I have not yet tested your solution, but will do it today and come back
> wtih the result.
Oh, right. So this will have no effect and you need to try the other
solution I mentioned in the first reply.

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

Re: [systemd-devel] nsapwned container terminal background color

2017-03-20 Thread arnaud gaboury 
On Mon, Mar 20, 2017 at 5:12 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Sun, Mar 19, 2017 at 09:30:05PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Sun, Mar 19, 2017 at 04:37:53PM +, arnaud gaboury wrote:
> > > I am trying with no success to have one background terminal color for
> the
> > > host and another one for the container.
> > >
> > > Some settings:
> > > - on host:
> > > window manager : i3
> > > terminal : urxvt-256
> > >
> > > -on container:
> > > no X, it is a server.
> > >
> > > Until now, I have tried to write a wrapper script to urxvt on host.
> This
> > > script is to test value of $HOST or $TERM, then fire urxvt with
> background
> > > color as option. This does not work.
> > >
> > > I have to figure out  that when i log my container, I am first on an
> urxvt
> > > terminal which become, once I am logged as user on container, a xterm.
> > > I am totally lost where to write instruction as the terminal color
> > > background: on host or container? and what app shall be tested to set
> the
> > > environment and decide the bg color (agetty?) ?
> >
> > Are you starting the container manually using systemd-nspawn in a
> terminal
> > emulator window?


Not really. The container is started at machine boot with
systemd-nspawn@container.service. Then, in one urxvt terminal, I log into
the container with :
# machinectl login container

I have not yet tested your solution, but will do it today and come back
wtih the result.

Thank you


> If yes, then the following works (tested with gnome-terminal,
> > but I think urxvt supports the same sequences):
> >
> > [Unit]
> > DefaultDependencies=no
> > Conflicts=shutdown.target
> >
> > [Service]
> > StandardOutput=tty
> > ExecStart=/usr/bin/printf '\033]11;darkgreen\007'
> > ExecStop=/usr/bin/printf '\033]11;black\007'
> > Type=oneshot
> > RemainAfterExit=true
> >
> > [Install]
> > WantedBy=basic.target
> >
> > (It would be nicer to undo the setting and return to whatever the old
> > background was, but I don't know how to do this.)
> I figured it out, although it's a bit ugly ;)
>
> ==> /etc/systemd/system/bgcolor.service <==
> [Unit]
> DefaultDependencies=no
> Conflicts=shutdown.target
> Description=Set terminal background
>
> [Service]
> StandardInput=tty
> StandardOutput=tty
> ExecStart=/usr/local/bin/bgcolor.sh start /run/bgcolor.txt teal
> ExecStop=/usr/local/bin/bgcolor.sh stop /run/bgcolor.txt
> Type=oneshot
> RemainAfterExit=true
>
> [Install]
> WantedBy=sysinit.target
>
> ==> /usr/local/bin/bgcolor.sh <==
> #!/bin/sh -e
>
> file="$2"
> field=11  # background
>
> if [ "$1" == "start" ]; then
> color="$3"
>
> oldstty=$(stty -g)
> stty raw -echo min 0
> #  OSC   Ps  ;Pt ST
> printf "\033]${field};?\033\\"
> IFS=';' read -t1 -r -d '\' answer
> echo "$answer" | sed 's/^.*\;//;s/[^rgb:0-9a-f/]//g' >"$file"
> stty "$oldstty"
>
> printf "\033]${field};${color}\007"
> elif [ "$1" == "stop" ]; then
> color=$(cat "$file")
> printf "\033]${field};${color}\007"
> fi
>
> This will set the background to teal during early boot, storing the
> original color in the specified file, and reset it back during
> shutdown. It seems to interfere with the systemd console output
> (newlines get messed up), and sometimes the restoration does not
> work. I suspect that both issues are caused by interference of
> systemd printing to the console concurrently with the script. Most
> likely putting a verify loop around the query for original
> color would fix the second issue.
>
> Zbyszek
>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Eric Biggers 
Hello,

The latest systemd README and NEWS claim that the userspace interface to the
in-kernel hash algorithms (CONFIG_CRYPTO_USER_API_HASH) is now required.

I don't know how much thought was put into this decision, but I think it's a
mistake security-wise.  AF_ALG sockets increase the kernel's attack surface by
allowing users to instantiate and use arbitrary crypto algorithms, in
combinations or ways which may not have been tested.  Indeed, historically there
have been a number of security vulnerabilities related to this feature, both in
the API itself and in the various crypto modules.  For this reason, I think
security-conscious users would prefer to have this kernel feature turned off.

Why exactly does systemd suddenly need this feature?  If it's really just to
compute hashes, then please do it in userspace instead.  Unless systemd *really*
needs to support using hardware crypto accelerators, there is no need to call
into the kernel just to compute hashes.  Or at the very least, make the
dependency optional.

Thanks!

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