Re: [systemd-devel] Method to solve a "ordering cycle"

[Daniel Spannbauer]

Am 09/07/2015 um 02:29 PM schrieb Daniel Spannbauer:
> Am 09/07/2015 um 01:56 PM schrieb Lennart Poettering:
>> On Mon, 07.09.15 08:10, Daniel Spannbauer (d...@marco.de) wrote:
>>
>>> Am 09/06/2015 um 03:50 PM schrieb Lennart Poettering:
 On Wed, 02.09.15 17:08, Daniel Spannbauer (d...@marco.de) wrote:

> Hello,
>
> I often have a ordering cycle so a service is deleted at boot.
>
> Is there a standard way of getting rid of that cycles or to find the
> cause of them?
 Well, when systemd finds one of these cyclic ordering dependencies it will
 print your the full chain of it in the logs. It's not too difficult to
 read that actually, as it starts with one unit, and then shows you the
 next one that is ordered after it, and then the next one, and so on,
 until it comes back to the original one which is supposed to be after
 that last one... Now it's just a matter to figure out where to break
 the cycle and drop the ordering dependency.

 Lennart

>>> H,
>>>
>>> the following log isfrom one of my machines:
>>>
>>> Sep 04 14:56:04 fry systemd[1]: Activating default unit: default.target
>>> Sep 04 14:56:04 fry systemd[1]: Trying to enqueue job
>>> multi-user.target/start/replace
>>> Sep 04 14:56:04 fry systemd[1]: ESC[1;39mFound ordering cycle on
>>> remote-fs-pre.target/startESC[0m
>>> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
>>> nss-lookup.target/start
>>> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to named.service/start
>>> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to ldap.service/start
>>> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
>>> remote-fs.target/start
>>> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
>>> owncloud_all.mount/start
>>> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
>>> remote-fs-pre.target/start
>>> Sep 04 14:56:04 fry systemd[1]: ESC[1;31mBreaking ordering cycle by
>>> deleting job nss-lookup.target/startESC[0m
>>> Sep 04 14:56:04 fry systemd[1]: Deleting job postfix.service/start as
>>> dependency of job nss-lookup.target/start
>> Your ordering cycle is this one, reading the logs from top to bottom:
>>
>>  remote-fs-pre.target → nss-lookup.target → named.service →
>>  ldap.service → remote-fs.target → owncloud_all.mount →
>>  remote-fs-pre.target
>>
>> Or in other words: named.target wants to be run before
>> nss-lookup.target, which wants to be run beofre remote-fs-pre.target,
>> which through owncloud_all.mount wants to run before remote-fs.target,
>> which wants to run before ldap.service which wants to run before
>> named.service, and that's your ordering cycle. 
>>
>> systemd cannot fulfill this ordering of course. It cannot run named
>> both before and after your remote mount owncloud_all.mount. This is
>> logically impossible, of course.
>>
>>> Which service generates the trouble and what should I do to get rid
>>> of this?
>> Well, you have to break the cycle somewhere. You probably should
>> remove the ordering dep either 
>>
>> 1) between nss-lookup.target and named.service, or 
>> 2) between named.service and ldap.service, or 
>> 3) between ldap.service and remote-fs.target.
>>
>> Pick one, depending on what you need.
>>
>> Unless you have a good reason to keep this specific ordering
>> dependency, I'd probably remove the ordering #3. In fact, I'd go as
>> far as file a bug against ldap and ask them to remove the dep in their
>> package, referring back to this ML thread. It's an ordering dependency
>> people should probably add if they need it, but not be in place by
>> default, since it's probably common to combine named and ldapd in one
>> installation.
>>
>> Hope this is useful,
>>
>> Lennart
>>
> Hello Lennart,
>
> yes, this helps a lot. I don't need a local named, but didn't realize
> that it was started.
> But I will also look at the other dependencies.
>
> Thanks al lot (also to Alexander E. Patrakov )
>

Hello,

another short question: Can I test the system without rebooting it to
find ordering cycles?

Regards

Daniel


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

Re: [systemd-devel] Method to solve a "ordering cycle"

[Daniel Spannbauer]

Am 09/08/2015 um 08:51 AM schrieb Daurnimator:
> On 8 September 2015 at 16:16, Daniel Spannbauer  wrote:
>> Can I test the system without rebooting it to
>> find ordering cycles?
> Try `systemd-analyze verify myfile.someunit`
Hmmm, this works only for one service. Can I also analyze the whole
systemd-start-process?

Regards

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

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/07/2015 11:28 AM, Richard Maw wrote:
> On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote:
>> How is this handled ? Should we put a big warning in sshd_config to hint
>> user to configure ListenAddress in sshd.socket in the case socket
>> activation is used ?
> 
>> Or should sshd simply ignore all listening addresses defined in sshd_config
>> when in socket activation mode ?
> 
> That would be my preferred solution. I may be missing something important 
> here,
> but I'd always assumed that sshd wouldn't need to worry about the listen
> address if something else was accepting the connections on the socket.
> 

The downside of this would be that starting the service directly (ie not
the socket unit) won't work anymore

> As another alternative though, you could consider the sshd_config file the
> canonical location for the listen address, and have a generator parse
> sshd_config, and write a drop-in snippet for sshd.socket to set the
> ListenAddress.

Indeed that would work and would solve the problem, however not sure
that sshd_config file will be available at the time when the generator
will need it.

Also the generator would have to be generic enough to parse and support
several config file syntax. And regarding the number of different config
file syntax (can even be xml !), I'm not sure it will be a good idea.

Do you think that would be something that systemd upstream would be
interested in ? Maybe there were already some discussions/works around
that ?

Thanks.

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

[systemd-devel] "File exists warning" on first boot

[Johan x Lundin]

Hello,

On a fresh boot (no /etc/machine-id yet), I'm getting:
systemd[1]: Failed to populate /etc with preset unit settings, ignoring: File
exists

The files that systemd is complaining about are installed by systemd
itself (/etc/systemd/system/getty.target.wants/getty@tty1.service and
/etc/systemd/system/multi-user.target.wants/remote-fs.target).

Is there any reason not to let these files be populated in /etc on first boot,
and remove the warning?

Best Regards,
Johan Lundin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Method to solve a "ordering cycle"

[Daurnimator]

On 8 September 2015 at 16:16, Daniel Spannbauer  wrote:
> Can I test the system without rebooting it to
> find ordering cycles?

Try `systemd-analyze verify myfile.someunit`
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Yeela Kaplan]

- Original Message -
> From: "Lennart Poettering" 
> To: "Yeela Kaplan" 
> Cc: systemd-devel@lists.freedesktop.org, "Oved Ourfali" 
> Sent: Sunday, September 6, 2015 4:56:29 PM
> Subject: Re: [systemd-devel] Cannot start service due to 
> 'systemd-tty-ask-password-agent --watch' not answering
> 
> On Thu, 03.09.15 04:39, Yeela Kaplan (ykap...@redhat.com) wrote:
> 
> > Hi all,
> > We have run into a problem starting a service on EL7.1.
> > We installed the same environment on two hosts, on the first one the
> > service started successfully and on the second one it failed to start.
> > 
> > On the machine failing when running:
> > systemctl start supervdsmd.service
> > 
> > we see that a child process `systemd-tty-ask-password-agent --watch`
> > is spawned by systemctl:
> >  
> > [root@green-vdsc ~]# pstree -p $$
> > bash(13179)─┬─pstree(13494)
> > └─systemctl(13440)───systemd-tty-ask(13441)
> > 
> > using strace -f we see that systemctl is waiting on a response from
> > systemd-tty-ask but never receives it and gets stuck forever polling:
> > 
> > [pid 14884] execve("/usr/bin/systemd-tty-ask-password-agent",
> > ["/usr/bin/systemd-tty-ask-passwor"..., "--watch"], [/* 31 vars */]) = 0
> > .
> > .
> > .
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\242\233\270\f9\257\326\257_\n\30\264\263\17\32\272\0058\331\245\236f\207\202\321(\322`pS\324\376"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "G\262_$\210%*\275Q`G\240\361F\323\306\254.\334\323]\314:!u\343H\200\227\1\206&"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\272\177J\330D\252\367\2\367w\302\230-\221'\267\365\376\214\217\334\327\245a\311\377\tfc\177\273j"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\324\230x\231\222\210\271-\22a\2134\202\274\\\373\305\231;\177\244e\246=k\204\216\327\340iG\17"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "3\210\234X\0N\202G\354\22WFt^\331V\344\32\\A\36\323[\302\370\363\371\210\211\t\2129"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "+\235\26\274\373R\34\377Rs9\370\273\370\t),V\276\v`\233^E\256\257lX#\27\23W"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\346\237\ru5\311\372\362K?2\203\300\246C2K(\4+\20\341t\4S\370\35\25}>\265\240"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "F\25\257j\233q\315W\25\334\306\233\217!\306$\255Y\33\364\0039Qy\2\223@o\235\257hw"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\324\316\10k*\332A\253\344^\5y\372\10I\375\216\372\271\277\205\2264\0\35>?]`\263\374\275"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\34P\10w\314e\270\226X\t\212\30\"\17.\334\3471\342B\334\272\315\351\367\324k\273S\363\323f"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "\210\230;\227\31\261\364A\301#\374\311\206?\17\202\2749\340\246\323gm\315\325\361\335K\200\6h\275"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > read(3,
> > "i\10Dl\5\312\222\376\10l\37\277X\341CIs\\\"\235{\315|\334\227\10>\246a\5,\36"...,
> > 120) = 120
> > poll([{fd=3, events=POLLIN}], 1, 100)   = 1 ([{fd=3, revents=POLLIN}])
> > 
> > systemctl is waiting for a response from its child process forever and does
> > not close it.
> > As a result, it never even tries to run the start command for our service
> > supervdsm.
> > So it looks like an issue either with systemd or the way our service
> > interacts with systemd.
> > 
> > Is anyone familiar with such an issue or has an idea why it happens and how
> > to fix it?
> 
> This is really a misconception about what
> systemd-tty-ask-password-agent actually does. It's job is to bring
> password queries from system components to the screen while you wait
> for systemctl to finish. This is useful for things like LUKS hdd
> encryption where the system might have to query the user for a
> passphrase to proceed starting units. Other cases where this is used
> is for passphrases of SSL certificates.
> 
> Unless you actually use LUKS or SSL certificates with a passphrase
> (with a web server that supports querying passwords via systemd's
> password querying mechanism), the agent does pretty much nothing.
> 
> The agent is forked off, waits for passwords to be queried, queries
> them when there are any, and then exits when systemctl finishes.
> 
> You can pass --no-ask-password to systemctl to 

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Richard Maw]

On Tue, Sep 08, 2015 at 10:05:05AM +0200, Francis Moreau wrote:
> On 09/07/2015 11:28 AM, Richard Maw wrote:
> > On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote:
> >> How is this handled ? Should we put a big warning in sshd_config to hint
> >> user to configure ListenAddress in sshd.socket in the case socket
> >> activation is used ?
> > 
> >> Or should sshd simply ignore all listening addresses defined in sshd_config
> >> when in socket activation mode ?
> > 
> > That would be my preferred solution. I may be missing something important 
> > here,
> > but I'd always assumed that sshd wouldn't need to worry about the listen
> > address if something else was accepting the connections on the socket.
> > 
> 
> The downside of this would be that starting the service directly (ie not
> the socket unit) won't work anymore

Does it?

I understood that the common configuration for socket activated sshd was to
have a sshd.service for if you want it to always be running, and a pair of
sshd@.service and sshd.socket.

The former runs with -D, and the latter runs with -i.

Presumably this would be sufficient information that sshd could be made to
ignore the listen address in the sshd_config if it's being run with -i.

> > As another alternative though, you could consider the sshd_config file the
> > canonical location for the listen address, and have a generator parse
> > sshd_config, and write a drop-in snippet for sshd.socket to set the
> > ListenAddress.
> 
> Indeed that would work and would solve the problem, however not sure
> that sshd_config file will be available at the time when the generator
> will need it.

Systemd generally assumes that /usr and /etc are already mounted when it starts,
so generators should be able to read /etc/ssh/sshd_config.

> Also the generator would have to be generic enough to parse and support
> several config file syntax. And regarding the number of different config
> file syntax (can even be xml !), I'm not sure it will be a good idea.

Surely the generator for sshd.socket.d/listen-address.conf only needs to be
able to read the sshd_config file.

> Do you think that would be something that systemd upstream would be
> interested in ? Maybe there were already some discussions/works around
> that ?

For parsing config files of other configuration systems, no, sysvinit and
/etc/fstab are mostly the only foreign configuration formats systemd cares
about.

These are also split out into the generator mechanism rather than parsed by
systemd directly.

Systemd tends not to carry service configuration for other software,
though the openssh upstream, or their distribution downstreams could
carry the code for a listen address configuration generator.

See http://www.freedesktop.org/software/systemd/man/systemd.generator.html for
how generators work and
https://github.com/systemd/systemd/blob/master/src/debug-generator/debug-generator.c
for an example.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Yeela Kaplan]

- Original Message -
> From: "Lennart Poettering" 
> To: "Yeela Kaplan" 
> Cc: systemd-devel@lists.freedesktop.org, "Oved Ourfali" , 
> "Dan Kenigsberg" 
> Sent: Tuesday, September 8, 2015 1:45:54 PM
> Subject: Re: [systemd-devel] Cannot start service due to 
> 'systemd-tty-ask-password-agent --watch' not answering
> 
> On Tue, 08.09.15 05:51, Yeela Kaplan (ykap...@redhat.com) wrote:
> 
> > > This is really a misconception about what
> > > systemd-tty-ask-password-agent actually does. It's job is to bring
> > > password queries from system components to the screen while you wait
> > > for systemctl to finish. This is useful for things like LUKS hdd
> > > encryption where the system might have to query the user for a
> > > passphrase to proceed starting units. Other cases where this is used
> > > is for passphrases of SSL certificates.
> > > 
> > > Unless you actually use LUKS or SSL certificates with a passphrase
> > > (with a web server that supports querying passwords via systemd's
> > > password querying mechanism), the agent does pretty much nothing.
> > > 
> > > The agent is forked off, waits for passwords to be queried, queries
> > > them when there are any, and then exits when systemctl finishes.
> > > 
> > > You can pass --no-ask-password to systemctl to turn off the agent. See
> > > the man page for details.
> > > 
> > 
> > Thank you for your response.
> > I have tried running:  strace -f systemctl --no-ask-password start
> > supervdsmd.service
> > and it still reproduces.
> > but now intead of:
> > bash(3448)─┬─pstree(3625)
> >└─strace(3618)───systemctl(3623)───systemd-tty-ask(3624)
> > 
> > I get:
> > bash(3448)─┬─pstree(3586)
> >└─strace(3564)───systemctl(3569)
> > 
> > Do you know what systemctl is waiting for then?
> 
> Most likely that supervdsmd.service finishes start-up. Maybe there's a
> bug in the unit file regarding notification when it finished start-up?
> 
> (You can also tell systemctl to just enqueue a start job, but not wait
> for it to complete. Use --no-block for that).

This is the unit file:
[Unit]
Description="Auxiliary vdsm service for running helper functions as root"
Requires=libvirtd.service

[Service]
Type=simple
LimitCORE=infinity
EnvironmentFile=-/etc/sysconfig/supervdsmd
ExecStart=/usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer" 
--sockfile "/var/run/vdsm/svdsm.sock"
Restart=always


The service works fine on other machines... this is the first time we see it..
and the service is able to start without systemd.. by just running: 
/usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer" --sockfile 
"/var/run/vdsm/svdsm.sock" 
but hangs for a long time without starting even when using --no-block..

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

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Lennart Poettering]

On Tue, 08.09.15 05:51, Yeela Kaplan (ykap...@redhat.com) wrote:

> > This is really a misconception about what
> > systemd-tty-ask-password-agent actually does. It's job is to bring
> > password queries from system components to the screen while you wait
> > for systemctl to finish. This is useful for things like LUKS hdd
> > encryption where the system might have to query the user for a
> > passphrase to proceed starting units. Other cases where this is used
> > is for passphrases of SSL certificates.
> > 
> > Unless you actually use LUKS or SSL certificates with a passphrase
> > (with a web server that supports querying passwords via systemd's
> > password querying mechanism), the agent does pretty much nothing.
> > 
> > The agent is forked off, waits for passwords to be queried, queries
> > them when there are any, and then exits when systemctl finishes.
> > 
> > You can pass --no-ask-password to systemctl to turn off the agent. See
> > the man page for details.
> > 
> 
> Thank you for your response.
> I have tried running:  strace -f systemctl --no-ask-password start 
> supervdsmd.service
> and it still reproduces. 
> but now intead of:
> bash(3448)─┬─pstree(3625)
>└─strace(3618)───systemctl(3623)───systemd-tty-ask(3624)
> 
> I get:
> bash(3448)─┬─pstree(3586)
>└─strace(3564)───systemctl(3569)
> 
> Do you know what systemctl is waiting for then?

Most likely that supervdsmd.service finishes start-up. Maybe there's a
bug in the unit file regarding notification when it finished start-up?

(You can also tell systemctl to just enqueue a start job, but not wait
for it to complete. Use --no-block for that).

Lennart

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

[systemd-devel] /dev or /tmp disappears when program is running

[Steven Shiau]

Dear systemd developers,
I encountered a very weird issue, i.e. the /dev or /tmp disappears when
program is running.
The client system is nfsroot (diskless), running on the Debian Sid with
Linux kernel 4.1.0-2-amd64. The PXE/NFS server is a Debian Live system
running NFS server by unfs3 [1], its mounting status is attached as
"server-table.txt", and the client's initial mounting status is attached
as "client-table.txt". You can see /dev/ is mounted as devtmpfs. This is
quite normal.
When a system deployment program (clonezilla [2]) is run in the diskless
client machine, suddenly the /dev/ is gone, as shown in the attached
file "client-table-dev-missing.txt". You can see "/dev/" is missing. To
narrow down the issue, I have switched to sysvinit, but still use
systemd-udevd on this Debian Sid system.

I am sure systemd-udevd is running:
(live)root@debian-192-168-7-1:~# ps -ef |grep udev |grep -v grep
root   1190  1  0 11:31 ?00:00:01
/lib/systemd/systemd-udevd --daemon
and its version is 225:
# /lib/systemd/systemd-udevd --version
225

However, the /dev still disappears. On different virtual machines,
sometimes it's /tmp (mounted with tmpfs) which disappears.

Could you please shed some light so that I can avoid this issue?
We have been working on solving this problem more than a week, but still
can not make it.
If you need more info, please let me know.
Thank you very much.

Steven.

[1] http://unfs3.sourceforge.net
[2] http://clonnezilla.org

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C
root@debian:~# df
Filesystem  1K-blocks Used  Available Use% Mounted on
tmpfs  100392  560  99832   1% /run
/dev/sr0   566684   566684  0 100% 
/lib/live/mount/medium
/dev/loop0 525312   525312  0 100% 
/lib/live/mount/rootfs/filesystem.squashfs
tmpfs  5019600 501960   0% 
/lib/live/mount/overlay
overlay50196072420 429540  15% /
tmpfs51200   5120   0% /run/lock
devtmpfs102400  10240   0% /dev
tmpfs  2007800 200780   0% /run/shm
tmpfs  5019608 501952   1% /tmp
cgroup 120 12   0% 
/sys/fs/cgroup
cgmfs 1000100   0% 
/run/cgmanager/fs
192.168.120.254:/home/partimag 1856259072 45424640 1716518912   3% 
/home/partimag
root@debian:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=100392k,mode=755)
/dev/sr0 on /lib/live/mount/medium type iso9660 (ro,noatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs 
(ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
overlay on / type overlay 
(rw,noatime,lowerdir=//filesystem.squashfs/,upperdir=/live/overlay//rw,workdir=/live/overlay//work)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
pstore on /sys/fs/pstore type pstore (rw,relatime)
devtmpfs on /dev type devtmpfs 
(rw,relatime,size=10240k,nr_inodes=121938,mode=755)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=200780k)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k,mode=755)
cgmfs on /run/cgmanager/fs type tmpfs (rw,relatime,size=100k,mode=755)
192.168.120.254:/home/partimag on /home/partimag type nfs4 
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.120.3,local_lock=none,addr=192.168.120.254)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
(live)root@debian-192-168-7-1:~# df
Filesystem 1K-blocks Used  Available Use% Mounted on
192.168.7.254:/tftpboot/node_root 50227272704 429568  15% /
devtmpfs   102400  10240   0% /dev
tmpfs 100392  440  99952   1% /run
none  501960   12 501948   1% /root
none  501960 5084 496876   2% /etc
none  50196012216 489744   3% /var
192.168.7.254:/usr50227272704 429568  15% /usr
tmpfs   51200   5120   0% /run/lock
tmpfs 2007800 200780   0% /run/shm
tmpfs 501960 

[systemd-devel] .nspawn settings files

[Alexey Shabalin]

2015-09-08 16:32 GMT+03:00 David Herrmann :

> Hi
>
> Here's the next version of systemd, v226:
> * nspawn learnt support for .nspawn settings files, that may
>   accompany the image files or directories of containers, and
>   may contain additional settings for the container. This is
>   an alternative to configuring container parameters via the
>   nspawn command line.
>
> Hello.
I was read man systemd.nspawn and create  /etc/systemd/nspawn/ctr1.nspawn
for ctr1 container:

[Network]
Bridge=br144

after run i can see in journal:
systemd-nspawn[2020]: [/etc/systemd/nspawn/ctr1.nspawn:12] Unknown lvalue
'Bridge' in section 'Network'

What is the problem?

-- 
Alexey Shabalin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] udev: build by-path identifiers for ATA

[David Milburn]

Hi Lennart,

On 09/06/2015 05:48 AM, Lennart Poettering wrote:

On Fri, 04.09.15 10:59, David Milburn (dmilb...@redhat.com) wrote:

Please file this issue as github PR:

https://github.com/systemd/systemd


Ok, did that.





+static struct udev_device *handle_scsi_ata(struct udev_device *parent, char 
**path)
+{


Please reading CODING_STYLE. We tend to place the opening bracket on
the same line as the function name.


+   struct udev *udev  = udev_device_get_udev(parent);
+   struct udev_device *targetdev;
+   struct udev_device *target_parent;
+   struct udev_device *atadev;
+   const char *port_no;
+
+   targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", 
"scsi_host");
+   if (targetdev == NULL)
+   return NULL;


Usually, we don' compare explicitly with NULL.


Ok, fixed that.




+
+   target_parent = udev_device_get_parent(targetdev);
+   if (target_parent == NULL)
+   return NULL;
+
+   atadev = udev_device_new_from_subsystem_sysname(udev, "ata_port",
+   
udev_device_get_sysname(target_parent));
+   if (atadev == NULL)
+   return NULL;
+
+   port_no = udev_device_get_sysattr_value(atadev, "port_no");
+   if (port_no == NULL) {
+   parent = NULL;
+   goto out;
+   }
+   path_prepend(path, "ata-%s", port_no);
+out:
+udev_device_unref(atadev);
+return parent;


Indentation is borked... Needs to be 8ch all the way.


Sorry, usually use tabs, fixed that.




+}
+
  static struct udev_device *handle_scsi_default(struct udev_device *parent, 
char **path)
  {


This is indication that the patch is not against git master, as this
has been reindented a while back to put the bracket on the same line
as the function name (see above). Please file these things as PRs,
which will catch these issues right away, as the patch is then checked
and test-built just by submitting it.


Ok, PR is against master.

Thanks for reviewing.

David

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

[systemd-devel] [ANNOUNCE] systemd v226

[David Herrmann]

Hi

Here's the next version of systemd, v226:

https://github.com/systemd/systemd/archive/v226.tar.gz

As usual, many bug-fixes and cleanups, but also a rather large set of
new features this time, including support for unified cgroups, many
DHCP improvements, extensions to the polkit integration, nspawn
configuration files, and many more.

Thanks to everyone who contributed to this release!

CHANGES WITH 226:

* The DHCP implementation of systemd-networkd gained a set of
  new features:

  - The DHCP server now supports emitting DNS and NTP
information. It may be enabled and configured via
EmitDNS=, DNS=, EmitNTP=, and NTP=. If transmission of DNS
and NTP information is enabled, but no servers are
configured, the corresponding uplink information (if there
is any) is propagated.

  - Server and client now support transmission and reception
of timezone information. It can be configured via the
newly introduced network options UseTimezone=,
EmitTimezone=, and Timezone=.  Transmission of timezone
information is enabled between host and containers by
default now: the container will change its local timezone
to what the host has set.

  - Lease timeouts can now be configured via
MaxLeaseTimeSec= and DefaultLeaseTimeSec=.

  - The DHCP server improved on the stability of
leases. Clients are more likely to get the same lease
information back, even if the server loses state.

  - The DHCP server supports two new configuration options to
control the lease address pool metrics, PoolOffset= and
PoolSize=.

* The encapsulation limit of tunnels in systemd-networkd may
  now be configured via 'EncapsulationLimit='. It allows
  modifying the maximum additional levels of encapsulation
  that are permitted to be prepended to a packet.

* systemd now supports the concept of user buses replacing
  session buses, if used with dbus-1.10 (and enabled via dbus
  --enable-user-session). It previously only supported this on
  kdbus-enabled systems, and this release expands this to
  'dbus-daemon' systems.

* systemd-networkd now supports predictable interface names
  for virtio devices.

* systemd now optionally supports the new Linux kernel
  "unified" control group hierarchy. If enabled via the kernel
  command-line option 'systemd.unified_cgroup_hierarchy=1',
  systemd will try to mount the unified cgroup hierarchy
  directly on /sys/fs/cgroup. If not enabled, or not
  available, systemd will fall back to the legacy cgroup
  hierarchy setup, as before. Host system and containers can
  mix and match legacy and unified hierarchies as they
  wish. nspawn understands the $UNIFIED_CROUP_HIERARCHY
  environment variable to individually select the hierarchy to
  use for executed containers. By default, nspawn will use the
  unified hierarchy for the containers if the host uses the
  unified hierarchy, and the legacy hierarchy otherwise.
  Please note that at this point the unified hierarchy is an
  experimental kernel feature and is likely to change in one
  of the next kernel releases.  Therefore, it should not be
  enabled by default in downstream distributions yet. The
  minimum required kernel version for the unified hierarchy to
  work is 4.2. Note that when the unified hierarchy is used
  for the first time delegated access to controllers is
  safe. Because of this systemd-nspawn containers will get
  access to controllers now, as will systemd user
  sessions. This means containers and user sessions may now
  manage their own resources, partitioning up what the system
  grants them.

* A new special scope unit "init.scope" has been introduced
  that encapsulates PID 1 of the system. It may be used to
  determine resource usage and enforce resource limits on PID
  1 itself. PID 1 hence moved out of the root of the control
  group tree.

* The cgtop tool gained support for filtering out kernel
  threads when counting tasks in a control group. Also, the
  count of processes is now recursively summed up by
  default. Two options -k and --recursive= have been added to
  revert to old behaviour. The tool has also been updated to
  work correctly in containers now.

* systemd-nspawn's --bind= and --bind-ro= options have been
  extended to allow creation of non-recursive bind mounts.

* libsystemd gained two new calls sd_pid_get_cgroup() and
  sd_peer_get_cgroup() which return the control 

Re: [systemd-devel] /dev or /tmp disappears when program is running

[Lennart Poettering]

On Tue, 08.09.15 20:45, Steven Shiau (ste...@nchc.org.tw) wrote:

> Dear systemd developers,
> I encountered a very weird issue, i.e. the /dev or /tmp disappears when
> program is running.
> The client system is nfsroot (diskless), running on the Debian Sid with
> Linux kernel 4.1.0-2-amd64. The PXE/NFS server is a Debian Live system
> running NFS server by unfs3 [1], its mounting status is attached as
> "server-table.txt", and the client's initial mounting status is attached
> as "client-table.txt". You can see /dev/ is mounted as devtmpfs. This is
> quite normal.
> When a system deployment program (clonezilla [2]) is run in the diskless
> client machine, suddenly the /dev/ is gone, as shown in the attached
> file "client-table-dev-missing.txt". You can see "/dev/" is missing. To
> narrow down the issue, I have switched to sysvinit, but still use
> systemd-udevd on this Debian Sid system.

What makes you think this is a systemd issue, and not a clonezilla issue?

Lennart

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

Re: [systemd-devel] containers again

[Richard Maw]

On Tue, Sep 08, 2015 at 04:14:58PM +0200, Michał Zegan wrote:
> Hello.
> 
> Before you stated that containers are not a security feature right
> now. It is required to manually shift uids/gids on images etc.

Yes.

Also, if you uid-shift the container's root directory, using `--private-users`
without specifying a uid-shift works by inspecting the uid-shift of the
file-system, assuming that each container is allocated the lower 16-bits of the
UID field, and the upper 16-bits being a container ID.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/08/2015 12:09 PM, Richard Maw wrote:
> On Tue, Sep 08, 2015 at 10:05:05AM +0200, Francis Moreau wrote:
>> On 09/07/2015 11:28 AM, Richard Maw wrote:
>>> On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote:
 How is this handled ? Should we put a big warning in sshd_config to hint
 user to configure ListenAddress in sshd.socket in the case socket
 activation is used ?
>>>
 Or should sshd simply ignore all listening addresses defined in sshd_config
 when in socket activation mode ?
>>>
>>> That would be my preferred solution. I may be missing something important 
>>> here,
>>> but I'd always assumed that sshd wouldn't need to worry about the listen
>>> address if something else was accepting the connections on the socket.
>>>
>>
>> The downside of this would be that starting the service directly (ie not
>> the socket unit) won't work anymore
> 
> Does it?
> 
> I understood that the common configuration for socket activated sshd was to
> have a sshd.service for if you want it to always be running, and a pair of
> sshd@.service and sshd.socket.
> 
> The former runs with -D, and the latter runs with -i.
> 

Ah no, with this design starting sshd.service should do the right thing
but that's because there're 2 different service unit files:
sshd@.service and sshd.service.

I suppose that was done because sshd wasn't modified to use systemd's
native socket passing interface (sd_listen_fds). If it was the case then
only one service unit file would be used I think. And in this case, the
service unit would start sshd in 'OnDemand' mode always. In this case we
can't start directly sshd.service, but have to use socket activation.

> Presumably this would be sufficient information that sshd could be made to
> ignore the listen address in the sshd_config if it's being run with -i.
> 

I'm not sure I'm understanding...

[...]
> 
> For parsing config files of other configuration systems, no, sysvinit and
> /etc/fstab are mostly the only foreign configuration formats systemd cares
> about.
> 
> These are also split out into the generator mechanism rather than parsed by
> systemd directly.
> 
> Systemd tends not to carry service configuration for other software,
> though the openssh upstream, or their distribution downstreams could
> carry the code for a listen address configuration generator.
> 
> See http://www.freedesktop.org/software/systemd/man/systemd.generator.html for
> how generators work and
> https://github.com/systemd/systemd/blob/master/src/debug-generator/debug-generator.c
> for an example.
> 

Thanks for the pointer. That makes sense although I'm not sure that
service projects are willing to include a systemd generator in their repo.

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

[systemd-devel] The $network LSB facility in initscripts

[Michael Chapman]

Hi all,

I was looking into how the $network LSB facility name was handled by 
systemd-sysv-generator, in particular with its interaction with 
network-pre.target. I think the generator might be missing a couple of 
cases.


Currently we have "Provides: $network" translated into:

  Before=network-online.target network.target
  Wants=network-online.target

Should this also generate:

  After=network-pre.target

to ensure that units ordered before this target are started before the 
initscript?


Similarly, "X-Start-Before: $network" is currently translated to:

  Before=network-online.target

but should it also generate:

  Before=network-pre.target
  Wants=network-pre.target

?

I think both of these changes would be necessary for network-pre.target to 
work properly when you've got initscripts with dependencies on $network.


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

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Lennart Poettering]

On Tue, 08.09.15 07:56, Yeela Kaplan (ykap...@redhat.com) wrote:

> > > Thank you for your response.
> > > I have tried running:  strace -f systemctl --no-ask-password start
> > > supervdsmd.service
> > > and it still reproduces.
> > > but now intead of:
> > > bash(3448)─┬─pstree(3625)
> > >└─strace(3618)───systemctl(3623)───systemd-tty-ask(3624)
> > > 
> > > I get:
> > > bash(3448)─┬─pstree(3586)
> > >└─strace(3564)───systemctl(3569)
> > > 
> > > Do you know what systemctl is waiting for then?
> > 
> > Most likely that supervdsmd.service finishes start-up. Maybe there's a
> > bug in the unit file regarding notification when it finished start-up?
> > 
> > (You can also tell systemctl to just enqueue a start job, but not wait
> > for it to complete. Use --no-block for that).
> 
> This is the unit file:
> [Unit]
> Description="Auxiliary vdsm service for running helper functions as root"
> Requires=libvirtd.service
> 
> [Service]
> Type=simple
> LimitCORE=infinity
> EnvironmentFile=-/etc/sysconfig/supervdsmd
> ExecStart=/usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer" 
> --sockfile "/var/run/vdsm/svdsm.sock"
> Restart=always
> 
> 
> The service works fine on other machines... this is the first time we see it..
> and the service is able to start without systemd.. by just running: 
> /usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer" --sockfile 
> "/var/run/vdsm/svdsm.sock" 
> but hangs for a long time without starting even when using --no-block..

Ah, you are saying that even with --no-block it will block? If so,
that indicates a D-Bus problem of some kind. Could you paste the
strace output of "systemctl --no-block --no-ask-password start ..."
somewhere please? What distro is this?

Lennart

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

Re: [systemd-devel] /dev or /tmp disappears when program is running

[Steven Shiau]

On 9/8/2015 PM 10:05, Lennart Poettering wrote:

On Tue, 08.09.15 20:45, Steven Shiau (ste...@nchc.org.tw) wrote:


Dear systemd developers,
I encountered a very weird issue, i.e. the /dev or /tmp disappears when
program is running.
The client system is nfsroot (diskless), running on the Debian Sid with
Linux kernel 4.1.0-2-amd64. The PXE/NFS server is a Debian Live system
running NFS server by unfs3 [1], its mounting status is attached as
"server-table.txt", and the client's initial mounting status is attached
as "client-table.txt". You can see /dev/ is mounted as devtmpfs. This is
quite normal.
When a system deployment program (clonezilla [2]) is run in the diskless
client machine, suddenly the /dev/ is gone, as shown in the attached
file "client-table-dev-missing.txt". You can see "/dev/" is missing. To
narrow down the issue, I have switched to sysvinit, but still use
systemd-udevd on this Debian Sid system.


What makes you think this is a systemd issue, and not a clonezilla issue?

Lennart

Thanks. The reason is the same versions of Clonezilla-related programs 
work on the Debian live system, i.e. not on nfsroot environment. 
Therefore I guess it maybe due to systemd-udevd with nfsroot. Maybe I am 
wrong.


Steven.

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Yeela Kaplan]

- Original Message -
> From: "Lennart Poettering" 
> To: "Yeela Kaplan" 
> Cc: systemd-devel@lists.freedesktop.org, "Oved Ourfali" , 
> "Dan Kenigsberg" 
> Sent: Tuesday, September 8, 2015 4:48:31 PM
> Subject: Re: [systemd-devel] Cannot start service due to 
> 'systemd-tty-ask-password-agent --watch' not answering
> 
> On Tue, 08.09.15 07:56, Yeela Kaplan (ykap...@redhat.com) wrote:
> 
> > > > Thank you for your response.
> > > > I have tried running:  strace -f systemctl --no-ask-password start
> > > > supervdsmd.service
> > > > and it still reproduces.
> > > > but now intead of:
> > > > bash(3448)─┬─pstree(3625)
> > > >└─strace(3618)───systemctl(3623)───systemd-tty-ask(3624)
> > > > 
> > > > I get:
> > > > bash(3448)─┬─pstree(3586)
> > > >└─strace(3564)───systemctl(3569)
> > > > 
> > > > Do you know what systemctl is waiting for then?
> > > 
> > > Most likely that supervdsmd.service finishes start-up. Maybe there's a
> > > bug in the unit file regarding notification when it finished start-up?
> > > 
> > > (You can also tell systemctl to just enqueue a start job, but not wait
> > > for it to complete. Use --no-block for that).
> > 
> > This is the unit file:
> > [Unit]
> > Description="Auxiliary vdsm service for running helper functions as root"
> > Requires=libvirtd.service
> > 
> > [Service]
> > Type=simple
> > LimitCORE=infinity
> > EnvironmentFile=-/etc/sysconfig/supervdsmd
> > ExecStart=/usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer"
> > --sockfile "/var/run/vdsm/svdsm.sock"
> > Restart=always
> > 
> > 
> > The service works fine on other machines... this is the first time we see
> > it..
> > and the service is able to start without systemd.. by just running:
> > /usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer" --sockfile
> > "/var/run/vdsm/svdsm.sock"
> > but hangs for a long time without starting even when using --no-block..
> 
> Ah, you are saying that even with --no-block it will block? If so,
> that indicates a D-Bus problem of some kind. Could you paste the
> strace output of "systemctl --no-block --no-ask-password start ..."
> somewhere please? What distro is this?

It's not blocking, but it also does not start the service so it is not a 
notification issue.. 

That's the strace:
https://paste.fedoraproject.org/264808/72290914/

It's RHEV-H 7.1. 
It is based on el7 with systemd-208-20.el7_1.5.x86_64.


Thank you!


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

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Yeela Kaplan]

- Original Message -
> From: "Lennart Poettering" 
> To: "Yeela Kaplan" 
> Cc: systemd-devel@lists.freedesktop.org, "Oved Ourfali" , 
> "Dan Kenigsberg" 
> Sent: Tuesday, September 8, 2015 6:23:56 PM
> Subject: Re: [systemd-devel] Cannot start service due to 
> 'systemd-tty-ask-password-agent --watch' not answering
> 
> On Tue, 08.09.15 10:47, Yeela Kaplan (ykap...@redhat.com) wrote:
> 
> > 
> > 
> > - Original Message -
> > > From: "Lennart Poettering" 
> > > To: "Yeela Kaplan" 
> > > Cc: systemd-devel@lists.freedesktop.org, "Oved Ourfali"
> > > , "Dan Kenigsberg" 
> > > Sent: Tuesday, September 8, 2015 4:48:31 PM
> > > Subject: Re: [systemd-devel] Cannot start service due to
> > > 'systemd-tty-ask-password-agent --watch' not answering
> > > 
> > > On Tue, 08.09.15 07:56, Yeela Kaplan (ykap...@redhat.com) wrote:
> > > 
> > > > > > Thank you for your response.
> > > > > > I have tried running:  strace -f systemctl --no-ask-password start
> > > > > > supervdsmd.service
> > > > > > and it still reproduces.
> > > > > > but now intead of:
> > > > > > bash(3448)─┬─pstree(3625)
> > > > > >└─strace(3618)───systemctl(3623)───systemd-tty-ask(3624)
> > > > > > 
> > > > > > I get:
> > > > > > bash(3448)─┬─pstree(3586)
> > > > > >└─strace(3564)───systemctl(3569)
> > > > > > 
> > > > > > Do you know what systemctl is waiting for then?
> > > > > 
> > > > > Most likely that supervdsmd.service finishes start-up. Maybe there's
> > > > > a
> > > > > bug in the unit file regarding notification when it finished
> > > > > start-up?
> > > > > 
> > > > > (You can also tell systemctl to just enqueue a start job, but not
> > > > > wait
> > > > > for it to complete. Use --no-block for that).
> > > > 
> > > > This is the unit file:
> > > > [Unit]
> > > > Description="Auxiliary vdsm service for running helper functions as
> > > > root"
> > > > Requires=libvirtd.service
> > > > 
> > > > [Service]
> > > > Type=simple
> > > > LimitCORE=infinity
> > > > EnvironmentFile=-/etc/sysconfig/supervdsmd
> > > > ExecStart=/usr/share/vdsm/daemonAdapter
> > > > "/usr/share/vdsm/supervdsmServer"
> > > > --sockfile "/var/run/vdsm/svdsm.sock"
> > > > Restart=always
> > > > 
> > > > 
> > > > The service works fine on other machines... this is the first time we
> > > > see
> > > > it..
> > > > and the service is able to start without systemd.. by just running:
> > > > /usr/share/vdsm/daemonAdapter "/usr/share/vdsm/supervdsmServer"
> > > > --sockfile
> > > > "/var/run/vdsm/svdsm.sock"
> > > > but hangs for a long time without starting even when using --no-block..
> > > 
> > > Ah, you are saying that even with --no-block it will block? If so,
> > > that indicates a D-Bus problem of some kind. Could you paste the
> > > strace output of "systemctl --no-block --no-ask-password start ..."
> > > somewhere please? What distro is this?
> > 
> > It's not blocking, but it also does not start the service so it is
> > not a notification issue..
> 
> Hmm? You wrote earlier that systemctl was hanging. Is it hanging or
> isn't it hanging?

I'm sorry, I used the wrong word. 
I meant that it is not blocking.
But it also does not start the service.
So eventually, that's our problem, that the service does not start.. even 
though systemd is not blocking. 
Maybe it's just an issue that happened on this specific host.


> 
> > That's the strace:
> > https://paste.fedoraproject.org/264808/72290914/
> 
> That shows that systemctl exits cleanly with exit code 0...
> 
> What precisely is the problem? You now say that systemctl wasn't
> hanging and show me that it exits with exit code 0, so there's nothing
> wrong from what I can see. Not sure what you are trying to say at all?
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Lennart Poettering]

On Tue, 08.09.15 11:29, Yeela Kaplan (ykap...@redhat.com) wrote:

> > Hmm? You wrote earlier that systemctl was hanging. Is it hanging or
> > isn't it hanging?
> 
> I'm sorry, I used the wrong word. 
> I meant that it is not blocking.
> But it also does not start the service.
> So eventually, that's our problem, that the service does not start.. even 
> though systemd is not blocking. 
> Maybe it's just an issue that happened on this specific host.

Hmm, what do you mean by "not starting"? Does "systemctl status" on
the service unit say it's up? Can you paste the output of this?

Did it start, but maybe just exit quickly?

Lennart

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

Re: [systemd-devel] Cannot start service due to 'systemd-tty-ask-password-agent --watch' not answering

[Yeela Kaplan]

- Original Message -
> From: "Lennart Poettering" 
> To: "Yeela Kaplan" 
> Cc: systemd-devel@lists.freedesktop.org, "Oved Ourfali" , 
> "Dan Kenigsberg" 
> Sent: Tuesday, September 8, 2015 6:51:30 PM
> Subject: Re: [systemd-devel] Cannot start service due to 
> 'systemd-tty-ask-password-agent --watch' not answering
> 
> On Tue, 08.09.15 11:29, Yeela Kaplan (ykap...@redhat.com) wrote:
> 
> > > Hmm? You wrote earlier that systemctl was hanging. Is it hanging or
> > > isn't it hanging?
> > 
> > I'm sorry, I used the wrong word.
> > I meant that it is not blocking.
> > But it also does not start the service.
> > So eventually, that's our problem, that the service does not start.. even
> > though systemd is not blocking.
> > Maybe it's just an issue that happened on this specific host.
> 
> Hmm, what do you mean by "not starting"? Does "systemctl status" on
> the service unit say it's up? Can you paste the output of this?
> 

when using 'ps' there is no such process.. 
and also for status:

systemctl status supervdsmd
supervdsmd.service - "Auxiliary vdsm service for running helper functions as 
root"
   Loaded: loaded (/usr/lib/systemd/system/supervdsmd.service; static)
   Active: inactive (dead)

Sep 02 06:37:36 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 06:42:12 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 07:30:52 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 08:23:59 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 11:08:51 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 12:16:32 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 13:25:02 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 13:37:48 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root".
Sep 02 13:41:10 green-vdsc.qa.lab.tlv.redhat.com systemd[1]: Stopped "Auxiliary 
vdsm service for running helper functions as root"

> Did it start, but maybe just exit quickly?
> 

If it would have started I'd expect to see it in our logs 
(/usr/share/vdsm/supervdsm.log) but there is no such indication.. 

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

[systemd-devel] containers again

[Michał Zegan]

Hello.

Before you stated that containers are not a security feature right now. 
It is required to manually shift uids/gids on images etc.
What are other known problems with containers that use ALL namespaces? 
Like if not counting the problem of uid allocation and manual shifting 
of them.

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

[systemd-devel] systemd 225: cannot override nspawn service

[crequill]

Hi,

With systemd 225 on an archlinux, I cannot override a nspawn service anymore.
Example:

One container named ci-container, declared as this :
# ls -al /etc/systemd/system/machines.target.wants/
total 8
drwxr-xr-x 2 root root 4096  8 sept. 16:06 .
drwxr-xr-x 8 root root 4096  8 sept. 16:06 ..
lrwxrwxrwx 1 root root   47  8 sept. 16:06 
systemd-nspawn@ci\x2dcontainer.service -> 
/usr/lib/systemd/system/systemd-nspawn@.service

With an override in /etc/systemd/system/systemd-nspawn@ci-container.service.d/
total 12
drwxr-xr-x 2 root root 4096  8 sept. 16:12 .
drwxr-xr-x 8 root root 4096  8 sept. 16:06 ..
-rw-r--r-- 1 root root  156  8 sept. 16:12 override.conf

Here is the file 
/etc/systemd/system/systemd-nspawn@ci-container.service.d/override.conf :
[Service]
ExecStart=
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot 
--link-journal=try-guest --network-macvlan=enp3s1f0 --private-network 
--directory=/var/lib/container/%i

But when the container boot, there is no macvlan interface in it.
This was working well with systemd 218. Where is the problem ?

Many thanks for your reply.
Christophe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Simon McVittie]

On 08/09/15 13:55, Francis Moreau wrote:
> On 09/08/2015 12:09 PM, Richard Maw wrote:
>> I understood that the common configuration for socket activated sshd was to
>> have a sshd.service for if you want it to always be running, and a pair of
>> sshd@.service and sshd.socket.
> 
> Ah no, with this design starting sshd.service should do the right thing
> but that's because there're 2 different service unit files:
> sshd@.service and sshd.service.

As far as I understand it, this duplication is present to give the
sysadmin a choice between two ways to run sshd, depending on this
particular ssh server's requirements.

If ssh access is frequently used or needs to work quickly (for instance
as the primary way to log in and fix things), enabling sshd.service
means it will start "eagerly", on boot. Debian and its derivatives
enable this by default (if sshd is installed).

If ssh access is infrequently used, a sysadmin can disable sshd.service
and enable sshd.socket instead. That means sshd will be started
on-demand, which will take a bit longer (particularly if the reason to
log in is that the server has hit performance problems), but reduces
resource consumption until then. This would be appropriate if the reason
for providing ssh access is as a rarely-used "developer console"
analogous to Android's adb, for instance.

-- 
Simon McVittie
Collabora Ltd. 

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