Re: [systemd-devel] auto-unmount via BindsTo= is annoying

[Mantas Mikulėnas]

On Sat, Apr 4, 2015 at 1:44 PM, Andrei Borzenkov arvidj...@gmail.com
wrote:

 В Sat, 4 Apr 2015 12:55:34 +0300
 Mantas Mikulėnas graw...@gmail.com пишет:

  On Sat, Apr 4, 2015 at 7:37 AM, Andrei Borzenkov arvidj...@gmail.com
  wrote:
 
   В Fri, 3 Apr 2015 21:19:24 +0300
   Mantas Mikulėnas graw...@gmail.com пишет:
  
Previously udev used to undo mounts when a device *disappeared;* when
systemd took over the task, it started unmounting things as soon as
 it
noticed that the device *doesn't exist right now.* While similar,
 the new
behavior can be annoying, since it also triggers if the device never
existed in the first place. For example:
   
~ My fstab has /dev/mapper/luks-backups → /mnt/backup. I want to
 mount
another disk there (which has a different label), but even though
 `mount
/dev/sdb1 /mnt/backup` succeeds, the directory remains empty and
 won't
   show
up in `findmnt`.
   
After a few retries I check dmesg and notice systemd saying that
mnt-backup.mount is bound to an inactive device; stopping. Which
 means,
if my fstab says disk X is mounted there, systemd won't let me mount
anything else but disk X at that location.
   
~ I had to boot to emergency mode due to reasons, and attempted to
 mount
/boot  /boot/efi in order to fix something. Since my fstab had
/dev/disk/by-partlabel/boot → /boot, any attempts to mount
 anything at
/boot get immediately undone – emergency mode has no udev, so I get
boot.mount is bound to an inactive device; stopping all over again.
   
  
   Do these commits help?
  
   commit 628c89cc68ab96fce2de7ebba5933725d147aecc
   Author: Lennart Poettering lenn...@poettering.net
   Date:   Fri Feb 27 21:55:08 2015 +0100
  
   core: rework device state logic
  
   commit 496068a8288084ab3ecf8b179a8403ecff1a6be8
   Author: Martin Pitt martin.p...@ubuntu.com
   Date:   Fri Mar 13 08:35:59 2015 +0100
  
   core: don't change removed devices to state tentative
  
 
  Nope, this is already on 093c2cfe3b1.
 
 

 I cannot reproduce it. Could you give more details (/etc/fstab line,
 systemctl status and systemctl show mnt-backup.mount before and after
 manual mount)?


Hmm, you're right, I cannot reproduce the /mnt/backup case either. Weird.
(I mostly remember it from 2 weeks ago.)

The /boot one though happened just yesterday:

-- 
Mantas Mikulėnas graw...@gmail.com
# systemctl status boot.mount
● boot.mount - /boot
   Loaded: loaded (/etc/fstab)
   Active: inactive (dead) since Sat 2015-04-04 14:32:18 EEST; 47s ago
Where: /boot
 What: /dev/disk/by-partlabel/boot
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 132 ExecUnmount=/bin/umount /boot -n (code=exited, status=0/SUCCESS)

# systemctl status /dev/disk/by-partlabel/boot
● dev-disk-by\x2dpartlabel-boot.device
   Loaded: loaded
   Active: inactive (dead)

# systemctl show boot.mount
Where=/boot
What=/dev/disk/by-partlabel/boot
Options=rw
Type=ext4
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
SloppyOptions=no
Result=success
ExecUnmount={ path=/bin/umount ; argv[]=/bin/umount /boot -n ; ignore_errors=no 
; start_time=[Sat 2015-04-04 14:32:18 EEST] ; stop_time=[Sat 2015-04-04 
14:32:18 EEST] ; pid=132 ; code=exited ; status=0 }
Slice=system.slice
MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615
Delegate=no
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=1885
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=1885
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=yes
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=boot.mount
Names=boot.mount
Requires=-.mount
RequiresOverridable=systemd-fsck@dev-disk-by\x5cx2dpartlabel-boot.service
Wants=system.slice
BindsTo=dev-disk-by\x5cx2dpartlabel-boot.device
RequiredBy=boot-efi.mount kernel-post-upgrade.path local-fs.target
WantedBy=dev-disk-by\x5cx2dpartlabel

Re: [systemd-devel] SystemD, Gnome permission problems

[Mantas Mikulėnas]

On Sat, Apr 11, 2015 at 1:57 AM, dean deanshann...@gmail.com wrote:

 Hi guys,

 Firstly i apologize if I'm in the wrong place, tell me where to go if i
 am ;-).

 I am having some permission problems, following is some syslog entries:

 gnome-session[2739]: (gnome-settings-daemon:2809):
 housekeeping-plugin-WARNING **: Failed to enumerate children of

 /tmp/systemd-private-4edf24dfb47a4c97917dcbd0468d3a56-colord.service-PxIGXf:
 Permission denied

 gnome-session[2739]:(gnome-settings-daemon:2809):
 housekeeping-plugin-WARNING **: Failed to enumerate children
 of /tmp/pulse-PKdhtXMmr18n: Permission denied

 gnome-session[2739]:(gnome-settings-daemon:2809):
 housekeeping-plugin-WARNING **: Failed to enumerate children of

 /var/tmp/systemd-private-4edf24dfb47a4c97917dcbd0468d3a56-systemd-timesyncd.service-HZKK6o:
 Permission denied

 gnome-session[2739]: (gnome-settings-daemon:2809):
 housekeeping-plugin-WARNING **: Failed to enumerate children of

 /var/tmp/systemd-private-4edf24dfb47a4c97917dcbd0468d3a56-colord.service-pIv5Bg:
 Permission denied

 I have changed permissions on the folders in /tmp but their either
 reverting or being recreated. Is this a Gnome or systemD problem?
 Its been this way for some time. What permissions are these
 files/folders supposed to be?

 Any help would be appreciated.


It's not much of a problem. Since /tmp is shared, software owned by various
users often has private subdirectories under it (which other uids cannot
access), and gnome-settings-daemon is just being unnecessarily verbose
about that.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?

[Mantas Mikulėnas]

On Sat, Apr 11, 2015 at 1:52 AM, lynd...@your-mail.com wrote:

 My /etc/systemd/system/sshd.service has a

   After=network-online.target

 dependency.

 ...

 Apparently, network-online waits for *real* interfaces only.


By itself, if I remember correctly, network-online.target doesn't wait
for *anything;
*it needs the provider-specific services to also be enabled, like
NetworkManager-wait-online.service (similarly for systemd-networkd and
ifupdown).

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Use a specific device ?

[Mantas Mikulėnas]

On Fri, Jun 5, 2015 at 4:22 PM, Harald Hoyer harald.ho...@gmail.com wrote:

 On 05.06.2015 15:09, poma wrote:
  On 05.06.2015 14:14, Jean-Christian de Rivaz wrote:
  Le 05. 06. 15 13:18, Aleksander Morgado a écrit :
  On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz j...@eclis.ch
 wrote:
  I have a system where the modem have multiple /dev/ttyACMx ports
 where x is
  not constant because of the dynamic nature of others serial devices.
  It may be worth noting that a very similar issue with the one faced
  here is the one with network interface names, where interface names
  were created as kernel drivers probed the different interfaces, ending
  up with eth0, eth1 and so on. Then, there would be network
  interface configurations for each network interface based on the name,
  but no one really ensured that the name was the same upon reboots. The
  solution provided by systemd to ensure that the proper configuration
  is applied always to the proper interface is to make the device names
  predictable, see:
 
 http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
 
  This solution avoids the need of any other udev rules to e.g. create
  network interface names containing the device MAC address or what not.
 
  I'm wondering whether the same could be applied not only to network
  interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up
  having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure,
  those names are a nightmare to type, but they are predictable (e.g. in
  this case by including the physical location of the connector of the
  hardware).
 
 
  This would be a wonderful solution. The only problem is when will this
  feature be available in a stable Linux kernel widely used by all majors
  distributions? Until this dream happens (probably not before severals
  years I guess), an other option must be implemented.
 
  Jean-Christian
 
 
  Face your broadband modem, live your dreams?
 
  Kay, when this would happen - Predictable Broadband Modem Interface
 Names?
 

 Wouldn't it be nicer to have symlinks like in /dev/disk ?
 /dev/tty/by-path/


60-serial.rules:16:ENV{ID_PATH}==?*, ENV{.ID_PORT}==,
SYMLINK+=serial/by-path/$env{ID_PATH}
60-serial.rules:17:ENV{ID_PATH}==?*, ENV{.ID_PORT}==?*,
SYMLINK+=serial/by-path/$env{ID_PATH}-port$env{.ID_PORT}

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd: IPForward with ipv6

[Mantas Mikulėnas]

IIRC, it is not quite a noop, but a logical AND between the two?

Or maybe it was an OR. I'm pretty sure now the 'forwarding' setting was an
OR between all  interface (but, some other setting was an AND). I might be
wrong though.

Anyway, different net.ipvx.conf settings have different rules, and it is
frankly confusing as duck. But they aren't broken nor ignored, no.

-- 
Mantas Mikulėnas
On Jun 8, 2015 23:00, Lennart Poettering lenn...@poettering.net wrote:

 On Wed, 03.06.15 19:18, Sébastien Luttringer (se...@seblu.net) wrote:

  Hello,
 
  Since systemd v220, IPForward= parameter in [Network] set kernel
  parameters by interface (/proc/sys/net/ipv[46]/conf/*/forwarding).
  This is nice and works perfectly for ipv4.
 
  Unfortunately, ipv6 forwarding doesn't works until we manually set
  /proc/sys/net/ipv6/conf/all/forwarding to 1.

 Are you saying that /proc/sys/net/ipv6/conf/$interface/forwarding is a
 NOP in the kernel for anything except $interface being all?

 That sounds seriously broken in the kernel. They should not expose a
 setting that is a NOP like that...

 
  In term of user experience, IPforward=ipv6 doesn't enable ipv6
  forwarding on the interface. That's tricked me.
 
  From:
  https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
 
  conf/all/forwarding - BOOLEAN
  Enable global IPv6 forwarding between all interfaces.
 
  IPv4 and IPv6 work differently here; e.g. netfilter must be
  used
  to control which interfaces may forward packets and which not.
 
  An maybe better explained here:
  http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html

 This documentation is not particularly good, but it certainly doesn't
 suggest the option was a NOP.

 Can you elaborate on this?

 Do you have any references that clarify that IPv6 and IPv4 handling of
 this setting is really different?

 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] Bind key combination to isolate emergency mode

[Mantas Mikulėnas]

On Sat, Jun 20, 2015 at 5:26 PM, Thomas Meyer tho...@m3y3r.de wrote:

 Hi,

 Is it possible to bind a key combination in systemd to perform a switch
 into emergency mode or another target?

 And would this key binding also work in situations where the system is
 under heavy cpu load and heavy swapping?


Sort of. There's a single key combination (Alt+ArrowUp by default) which
maps to kbrequest.target, though it only works on the console and not
within Xorg  the likes. You can pull in emergency.target via that.

Also don't forget the magic SysRq keys – Alt+SysRq+F will run the OOM
killer in case of heavy swapping, Alt+SysRq+E/I will sigterm/sigkill all
programs (systemd will restart gettys afterwards), and Alt+SysRq+N will
renice high-priority processes. You need to enable this via sysctl.conf
though.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SysVInit service migration to systemd

[Mantas Mikulėnas]

On Fri, Jun 26, 2015 at 4:15 PM, Lesley Kimmel ljkimme...@hotmail.com
wrote:

 Hi all;

 I've been working with RHEL5/6 for the past several years and have
 developed many init scripts/services which generally use lock files and PID
 files to allow for tracking of the service status. We are moving to RHEL7
 (systemd) in the near future and I am looking for instruction or tutorials
 on how to effectively migrate these scripts to work with systemd.

 I found https://wiki.archlinux.org/index.php/Systemd#Service_types which
 seems somewhat promising but it is fairly high-level. It looks like I may
 be able to use the 'forking' type with the 'pidfile' parameter to somewhat
 mimic what the scripts to today. However, I have a couple of questions:


Usually systemd detects the main process even without PIDFile, using
cgroups to keep track.


 -How does systemd track whether it should be stopping a service at
 shutdown (analogous to the /var/lock/subsys files in SysVInit)?


All service control requests go through the always-running init process, so
it can just keep track of service status internally without having to write
it out.

[This also means services run in a clean environment and can't ask for
interactive input when starting. Upstart and even /etc/inittab also work
the same way.]

Systemd also monitors whether the service processes are actually running –
by putting each into a separate cgroup – so it generally avoids issues such
as stale pidfiles.


 -Are there merits to using the notify or dbus types? If so does anyone
 know of a tutorial I could use to get to that point? (FYI, I'm not a
 developer but I learn complicated things quickly).


Similar to Type=forking, they both let systemd know whether the service is
ready or still initializing (which can't be done with the default
Type=simple).

Type=dbus might be best for creating DBus-activatable services compatible
with regular dbus-daemon, since it has mostly the same expectations as
dbus-daemon: the service doesn't fork, and is considered ready as soon as
it finally claims the configured BusName.

Type=notify is somewhat more lightweight – the service just needs to send
READY=1 over a Unix socket. (The service can also show some additional
information in `systemctl status` – e.g. lldpd could send STATUS=No
neighbors). libsystemd has sd_notify(3)
http://www.freedesktop.org/software/systemd/man/sd_notify.html for this,
though it could be done using regular socket API.

I suppose the same notify socket could be exposed to all other service
types. I don't know why it isn't yet.


 -If the current service logs to a custom, dedicated log is there a way to
 get systemd to provide the same type of output that it does for the
 built-in system services or must I make some modifications to integrate
 with journald?


`systemctl status` only reads from the journal.

The journal, however, also receives messages sent using the traditional
syslog API or written to the kernel log – in addition to its native
sd_journal_send(3)
http://www.freedesktop.org/software/systemd/man/sd_journal_send.html – so
that already covers most services.

You could also use rsyslogd to feed messages from custom text logs into the
journal, using its omjournal module.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[Mantas Mikulėnas]

On Sun, Jun 14, 2015 at 4:21 PM, cee1 fykc...@gmail.com wrote:

 Hi all,

 Why we need to read/save random seed? Can it be read from /dev/random each
 time?


Well, that would sorta defeat the point.

The random seed isn't for systemd's use. On boot, it is *written to*
/dev/random,
not read from it. Early during boot, the system has very little entropy
available from other sources, so it is common to save some random data from
last boot and provide it to the PRNG later.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl as non-root

[Mantas Mikulėnas]

On Fri, May 29, 2015 at 1:02 PM, Lennart Poettering lenn...@poettering.net
wrote:

 On Thu, 28.05.15 17:21, aaron_wri...@selinc.com (aaron_wri...@selinc.com)
 wrote:

  Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM:
   Access to the system dbus is controlled by dbus policies. You will
   need to write a policy for giving this user access to the systemd1
  object.
  
 
  I compiled systemd without dbus support (--disable-dbus), and there is no
  dbus daemon or dbus lib on the system. Is that a requirement to get the
  functionality I want? I didn't see much need for dbus as the system works
  quite well without it. Well, except for this of course.

 systemd will always use D-Bus (the protocol) for IPC, that's not
 optional, and you cannot turn it off neither during build-time nor
 during runtime. systemd does not use libdbus to implement this
 however, but instead it uses its own D-Bus client implementation,
 dubbed sd-bus, which is going to be a public API with the next
 systemd release.

 Optional however is whether dbus-daemon (the daemon) is used as for
 IPC, or if all dbus IPC takes place only between systemd and its
 clients via direct AF_UNIX connections, without the central bus
 concept. We support this mode mostly to cover for the early-boot phase
 where dbus-daemon is not running yet, and hence cannot be used for
 communication. Running in this mode even during normal operation is
 supported, but not recommended (which is why the README says: dbus is
 strictly speaking optional, but recommended).

 The direct AF_UNIX communication is available exclusively for
 privileged clients. Normally it's the duty of dbus-daemon to enforce
 more complex policy on dbus1 systems. If you take dbus-daemon out of
 the equation however, then this policy component will be missing, and
 hence systemd refuses to talk to any unprivileged clients.


Hmm, in a kdbus world, systemd (the service) itself would be responsible
for policy checks anyway, wouldn't it? I mean, it already does the
polkit/selinux checks even on dbus1 systems.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl disable service not working as expected

[Mantas Mikulėnas]

On Fri, May 29, 2015 at 3:04 PM, Belal, Awais awais_be...@mentor.com
wrote:

 Hi Martin,

 Thanks for the very quick reply :)
 So, are you saying that there is no guaranteed way in which PA can be
 enabled/disabled in a systemd based system?


pulseaudio is *very rarely* run as a system service in the first place.
Whether it's systemd-based or not is irrelevant.

Most often it's managed at session level, e.g. started during login by
gnome-session, sometimes `systemctl --user`, but usually launched
automatically by libpulse.

That too, if I want to keep the binary in so if a user needs he can
 enable/disable PA as per need. How can I disable PA in such a scenario?


You could set autospawn = no in pulse-client.conf(5).

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to keep certain services or mounts active during shutdown?

[Mantas Mikulėnas]

On Thu, Jul 2, 2015 at 1:24 PM, Frank Steiner fsteiner-ma...@bio.ifi.lmu.de
 wrote:

 Hi,

 for our diskless clients I setup the network and the root fs in the
 kernel/initrd and do two additional mounts in the initrd which are
 specific for every client.

 I understand the boot concept with its dependencies and ordering but I've
 no idea how to influence the shutdown process in two ways:

 1. I want to keep the network running. To avoid problems with dependencies
I had to keep it enabled although all the stuff is done in the
 kernel/initrd.
Thus, it shuts down during reboot and the diskless client hangs of
 course.

Changing the ExecStop to /usr/bin/true does work, but I wonder if there
is a better way in general to remove a process from the shutdown tree.
In SysV I just did inserv -r network in halt.local so that the
 shutdown
link was removed before it would be considered.

Is there something similar for systemd? systemctl disable network
didn't work.


No. Being an actual service manager, systemd keeps track _internally_ of
which services are active at any moment. Filesystem changes won't affect
that. (Messing around with service state was a bad idea in general, even
with sysvinit.)

If the 'main' network.service doesn't do anything anyway (since the network
is already up), you can replace it entirely with Type=oneshot,
ExecStart=/bin/true, RemainAfterExit=yes, essentially a service that does
nothing at all (but still satisfies dependencies).

(If you _actually_ meant remove a process instead of remove a service,
then yes, there are some other methods, such as KillMethod= or the @
prefix [2]. But that isn't of much use for NFS, I think.)

2. The two additional NFS mounts should be kept active, too. There are no
   *.mount files for them in /run/systemd/generator, because they are
   mounted in the initrd I guess.


Not sure about this one. I wonder if the shutdown initramfs feature [1]
would help here.

[1]: http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/
[2]: http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SysVInit service migration to systemd

[Mantas Mikulėnas]

On Jun 29, 2015 16:58, Lesley Kimmel ljkimme...@hotmail.com wrote:

 Jonathan;

 Thanks for the background and information. Since you clearly seem to have
a grasp of systemd please humour me with a few more questions (some of them
slightly ignorant):

 a) Why are PID bad?
 b) Why are lock files bad?
 c) If a/b are so bad why did they persist for so many years in SysVInit?

init itself *doesn't need* either, though it only supports non-forking
services, and in practice the only service it ever manages is agetty. (And
sometimes xdm.)

But the init.d scripts, they're just she'll scripts which aren't capable of
any persistent monitoring. They cannot rely on pid1 to do any monitoring.
So pidfiles and lockfiles are the only (or at least the simplest) way for
these scripts keep state from init.d/foo start across to init.d/foo
stop.

Personally I would say they persisted in sysvinit because they pretty much
/define/ the sysvinit design (i.e. pid1 that does almost nothing, and
short-lived external scripts).

Though there's also openrc, which also runs on top of sysv pid1, but that's
really all I know about it. I wonder how it tracks processes. I heard it
uses cgroups?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] HEADS-UP: splitting python-systemd out

[Mantas Mikulėnas]

On Tue, Jul 7, 2015 at 5:11 AM, Michael Biebl mbi...@gmail.com wrote:

 Hi!

 2015-07-07 2:51 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
  The new separated package is at
 https://github.com/systemd/python-systemd

 ..

  Following the example of libudev, I bumped the version of the separated
  package to 230, so that it is guaranteed to stay larger than the last
  version of systemd still containing python-systemd.


 Do you intend to publish release tarballs somewhere or should we get one
 from
 https://github.com/systemd/python-systemd/releases ?

 Btw, does anyone know if those release tarballs are generated by
 github on the fly and might have different md5sums?


They should be identical regardless – git-archive tries to generate
reproducible archives (assuming same parameters), and afaik that's also
what GitHub uses.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Monitoring services start event from kdbus with sd-bus API

[Mantas Mikulėnas]

First, are you actually switching your bus connection to monitor mode? In
kdbus (and probably even in future DBus) there is a distinct monitor mode
which must be enabled to capture other peers' bus traffic. Adding a match
is not enough for that.

Second, your approach won't work anyway. There *won't be* method_calls for
services that are started as dependencies, there won't be method calls for
socket-activated services, there won't be method calls for DBus-activated
services, there probably won't be even a single Start call during the
entire boot process. Systemd won't bother calling itself over DBus for that.

Instead, why not use the *signals* that systemd sends, for exactly such
purposes? You'll need to call Subscribe() to enable them.

See also what Plymouth does for its splash screen.

On Tue, Jun 30, 2015, 12:15 Thomas Schmidt t.schm...@md-network.de wrote:

 Hello,
 for an embedded project I’m implementing a bootsplash application which
 should as well display service names are starting.
 This is based on kdbus and uses the sd-bus API to communicate with systemd
 (for example boot process percentage property is polled).
 Now I try to monitor the kdbus (system bus) to capture the events which
 indicate that a service was started. (works very well for testing with
 busctl monitor“ tool).
 I assumed that the method_call „StartUnit“ would be a good indicator, so I
 tried to monitor for those messages by using following code (shortened and
 only significant parts copied here):

 -.-.-.-.-.-.-.-.-.-.-. schnipp -.-.-.-.-.-.-.-.-.-.-

 r = sd_bus_open_system(bus);
 …
 r = sd_bus_add_match(bus, NULL, , do_something_callback,  NULL); /*
 should not filter anything, I expect it triggers on any message */
 …

 for (;;) {
 sd_bus_message *m = NULL;

 r = sd_bus_process(bus, m);
 if (r  0) {
 fprintf(stderr, Failed to process bus: %s\n,
 strerror(-r));
 goto finish;
 }

 if (r  0) /* we processed a request, try to process
 another one, right-away */
 continue;

 /* Wait for the next request to process */
 r = sd_bus_wait(bus, (uint64_t) -1);
 if (r  0) {
 fprintf(stderr, Failed to wait on bus: %s\n,
 strerror(-r));
 goto finish;
 }

 }
 …

 -.-.-.-.-.-.-.-.-.-.-. schnapp -.-.-.-.-.-.-.-.-.-.-

 The interesting thing is that this code only sees „signal“ type  messages
 - but not any other like „method_call“.

 I did extensive testing, tried different code variants, for example by
 processing sd_bus_message *m“ directly in the for loop with
 „sd_bus_message_is_method_call“ - but the effect is the same I don’t get
 „method_call“ as an event.

 Is there any suggestion what could be the reason ? (is that generally the
 right way what I try here to do ?)

 Many thanks for any feedback which points me to the right direction
 Kind Regards
 Thomas Schmidt


 ___
 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] udev now crashes in daemon mode

[Mantas Mikulėnas]

So, udev v220 crashes in my initramfs with the following message:

 starting version v220
 Assertion 'manager-pid == getpid()' failed at src/udev/udevd.c:568,
function ev
 Aborting.

It seems main calls manager_new() before forking, so the parent PID is
stored instead of child PID.

(I'm using Arch Linux with the traditional mkinitcpio-based initramfs,
which starts udev using systemd-udevd --daemon --resolve-names=never.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to wait for specific interface/IP?

[Mantas Mikulėnas]

On Sat, May 23, 2015 at 7:03 PM, Ian Pilcher arequip...@gmail.com wrote:

 Is there a simple way to make a service require that a specific network
 interface/IP address be active?

 I have a manually set up bridge and dnsmasq configuration for my VM
 traffic, but dnsmasq is getting started before NetworkManager has
 configured the bridge and failing because it cannot bind to the bridge's
 IP address.


dnsmasq has the bind-dynamic option for such situations.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev now crashes in daemon mode

[Mantas Mikulėnas]

Thanks, finally got around to rebooting, and udev now starts properly.
However, when the cleanuphook calls udevadm control --exit, it takes
quite a while (though the system later boots normally). With --debug
enabled, I see:

 udevd message (EXIT) received
 [10-20 seconds pass]
 timeout, giving up waiting for workers to finish

I tried running it manually from the initramfs shell, and udev had no
workers at all at that point.

This is with the latest 185abfc3d6b build.

On Sun, May 24, 2015 at 4:30 PM, Tom Gundersen t...@jklm.no wrote:

 Hi Mantas,



 On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas graw...@gmail.com
 wrote:
  So, udev v220 crashes in my initramfs with the following message:
 
  starting version v220
  Assertion 'manager-pid == getpid()' failed at src/udev/udevd.c:568,
  function ev
  Aborting.
 
  It seems main calls manager_new() before forking, so the parent PID is
  stored instead of child PID.
 
  (I'm using Arch Linux with the traditional mkinitcpio-based initramfs,
 which
  starts udev using systemd-udevd --daemon --resolve-names=never.)

 Thanks for the report. This should be fixed now in git, please let me
 know if that is not the case.

 Cheers,

 Tom




-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to call dbus ListUnits for user units?

[Mantas Mikulėnas]

On Tue, May 26, 2015 at 9:33 PM, Chris Morgan chmor...@gmail.com wrote:

 But I can't seem to figure out how to do the same for user units.
 There doesn't seem to be an org.freedesktop.systemd1 interface on my
 current user's session bus and I wasn't able to spot anything in the
 interfaces on the system bus that had a nested interface of
 org.freedesktop.system1.Manager...


The first org.freedesktop.systemd1 here is a /service/ name; the usual
hierarchy is bus - service - object - interface - method, no such thing as
nested interfaces.

Anyway. The user processes are not allowed to own service names on the
system bus. And `systemd --user` is a per-user service, not a per-session
one, so it cannot be on the session bus for various reasons: it doesn't
know the bus address; it needs to outlive the session bus; the user might
sometimes have multiple sessions with their own 'session bus' instances.

So the idea is that `systemd --user` would be found on the /user/ bus,
which would someday replace the 'session' bus entirely.

But right now, the 'user' bus does not exist by default. To create it, you
need either
a) enable/install/boot with kdbus,
or b) obtain the dbus.service  dbus.socket user units. (They're in
dbus-git, or various other places like 
https://wiki.archlinux.org/index.php/Systemd/User#D-Bus.)

Configured this way, the 'user' bus won't replace the session bus yet, but
you *will* be able to connect to it and reach systemd, at address
kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network configuration

[Mantas Mikulėnas]

On Mon, Aug 17, 2015 at 2:25 PM, Michał Zegan webczat_...@poczta.onet.pl
wrote:

 Well, actually, are things like ip rules never used?
 It could be a specific use case, but is this a category of never used
 stuff, or legacy stuff? I do not use them myself, but I am curious.


I kind of wish networkd or NetworkManager could add rules for source-based
routing by default – it would make some configurations (like two default
routes) much easier to use...

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Option substitution in unit configuration files?

[Mantas Mikulėnas]

On Sun, Aug 16, 2015 at 5:36 PM, Malte Forkel malte.for...@berlin.de
wrote:

 Hi,

 Is there some kind of option substitution in unit configuration files?

 In a service configuration file, I specify the PID file and would like
 to re-use its name, e.g.
 PIDFile=/var/run/myservice.pid
 ExecStartPre=/usr/bin/touch %PIDFile ; /bin/chown myuser %PIDFile


Generally there isn't, at least not for referencing unit options.

But for unprivileged access to pidfiles the usual approach is to create a
dedicated subdirectory under /run¹, either using RuntimeDirectory= or a
full tmpfiles.d config, and tell the service to use
/run/myservice/myservice.pid. It might be simpler than touch+chown, and a
bit cleaner.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev uaccess tag does not support hotplug for some devices

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 3:18 PM, Robert Milasan rmila...@suse.cz wrote:
 On Wed, 19 Aug 2015 17:45:28 +0800
 Tom Yan tom.t...@gmail.com wrote:

 Hi all!

 So I added the following rules:
 [tom@localhost ~]$ grep . /etc/udev/rules.d/*
 /etc/udev/rules.d/uas.rules:DRIVERS==uas, TAG+=uaccess
 /etc/udev/rules.d/usb-storage.rules:DRIVERS==usb-storage,
 TAG+=uaccess

 Can you try:

 ACTION==add|change, SUBSYSTEMS==usb,
 ENV{ID_USB_DRIVER}==usb-storage, TAG+=uaccess

 in usb-storage.rules ?

 You might wanna rename the rule to something like 90-usb-storage.rules,
 but thats besides the point.

Hmm, in fact, the uaccess tag is consumed by:

73-seat-late.rules:15:TAG==uaccess, ENV{MAJOR}!=, RUN{builtin}+=uaccess

So the ordering might be very relevant.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser igei...@devonit.com wrote:
 Greetings, I am struggling with search queries here so I need to ask this
outright.  what is the role of dbus going forward?  Is dbus the preferred
way going forward?  Or should things really be using sd-bus.h instead?

D-Bus is not going away, only its internals are being replaced. Existing
clients will continue working.

kdbus replaces the dbus-daemon router and the Unix socket transport with
a direct kernel API, but all existing programs can still connect to it via
systemd-bus-proxy (at least until they get native kdbus support).

sd-bus.h is only a library for writing DBus clients  servers. Here the
choice is still up to you – sd-bus has better performance and native kdbus
support (and a better API than e.g. dbus-glib), but if you're writing
programs in GTK or Qt or EFL, then you'll still want GDBus or QtDBus or
Eldbus.

(I've heard GDBus already has native kdbus support in development, too.)

 I manage an embedded product that leverages system heavily at the system
level, but I want to expand this into the user session. The main focus is
to use scopes for classification and control of specific application's
process groups.  The rub here is that while system-run can do this if I try
to do this via dbus the org.freedesktop.systemd1 is missing from the user
session no matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am
using systemd  224.

Right, systemd will not be accessible on a session bus, since it runs
*outside* the session.

So instead you'll find it on the *user* bus, which is available by default
on kdbus systems, but can be configured with dbus-daemon as well. The
current devel branch (1.9.20) of dbus-daemon installs the --user units
dbus.socket and dbus.service necessary for this. The user bus address is
kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes (if I got the
syntax right?), or
kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus.

(Technically the same can be done with dbus 1.8.x as well, but AFAIK the
developers do not approve.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 4:47 PM, Ian Geiser igei...@devonit.com wrote:

 On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser igei...@devonit.com wrote:
  Greetings, I am struggling with search queries here so I need to ask
 this outright.  what is the role of dbus going forward?  Is dbus the
 preferred way going forward?  Or should things really be using sd-bus.h
 instead?



 D-Bus is not going away, only its internals are being replaced. Existing
 clients will continue working.



 kdbus replaces the dbus-daemon router and the Unix socket transport with
 a direct kernel API, but all existing programs can still connect to it via
 systemd-bus-proxy (at least until they get native kdbus support).



 sd-bus.h is only a library for writing DBus clients  servers. Here the
 choice is still up to you – sd-bus has better performance and native kdbus
 support (and a better API than e.g. dbus-glib), but if you're writing
 programs in GTK or Qt or EFL, then you'll still want GDBus or QtDBus or
 Eldbus.



 *[igeiser] *Awesome, thanks for the clarification



 (I've heard GDBus already has native kdbus support in development, too.)


  I manage an embedded product that leverages system heavily at the system
 level, but I want to expand this into the user session. The main focus is
 to use scopes for classification and control of specific application's
 process groups.  The rub here is that while system-run can do this if I try
 to do this via dbus the org.freedesktop.systemd1 is missing from the user
 session no matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am
 using systemd  224.

 Right, systemd will not be accessible on a session bus, since it runs
 *outside* the session.



 So instead you'll find it on the *user* bus, which is available by
 default on kdbus systems, but can be configured with dbus-daemon as well.
 The current devel branch (1.9.20) of dbus-daemon installs the --user units
 dbus.socket and dbus.service necessary for this. The user bus address is
 kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes (if I got the
 syntax right?), or
 kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus.

 *[igeiser] *Can I access it using the path directly in 1.8.x using
 ”unix:path=/run/user/$UID/system/private”? Or is that what the 1.9.20
 allows to happen?


Not quite; …/systemd/private is not even a bus – it's a direct peer-to-peer
connection to systemd, providing just that one service. (It is therefore
independent of which dbus-daemon version you're running.)

So you need to connect to it in a slightly different way
(e.g. g_dbus_connection_new_for_address()).

Also keep in mind that this socket is for internal systemd use only (hence
its name), and can be removed from systemd *at any time *in some future
release. For your own projects it's better to set up the actual user bus.


 (Technically the same can be done with dbus 1.8.x as well, but AFAIK the
 developers do not approve.)



 *[igeiser] *Is this the method various “user units” howtos add a
 dbus.socket and dbus.service into the user directory?  I will research the
 dbus repo for their details.  This is happy lab fun time so I am play with
 hacks if they don’t lead me away from the official solution.


Yes, that would work. (Though e.g. if you use polkit it should be the very
latest version as well.)

[Also that's some *weird* quoting style of yours]

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 7:13 PM, Simon McVittie 
simon.mcvit...@collabora.co.uk wrote:

 On 19/08/15 14:12, Mantas Mikulėnas wrote:

  The user bus address is

 ... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
 need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
 compatibility with older versions, or reimplementations like dbus-sharp.


(Aside: This reminds me of last year's attempt to make $DISPLAY default to
/run/user/*/X11-display … Back then, the last argument was that old
programs require $DISPLAY anyway, so having a default value is pointless.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 7:48 PM, Michał Zegan webczat_...@poczta.onet.pl
wrote:

 I may not understand something, but how does it work when I have things
 like at-spi2-registryd running on my session? I cannot start one local and
 one remote gui session, for example? Of course I mean the user bus.


I don't know how at-spi works in general. But AFAIK it launches its own
separate bus anyway (I see dbus-daemon
--config-file=/etc/at-spi2/accessibility.conf), so it could continue doing
that.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] grant users access to certain services only

[Mantas Mikulėnas]

On Fri, Aug 21, 2015 at 1:29 PM, Dominick Grift dac.overr...@gmail.com
wrote:

 On Fri, Aug 21, 2015 at 01:10:51PM +0300, Mantas Mikulėnas wrote:
 snip

  
   i think it kind of sucks that systemctl --user list-units can be used
 to
   determine who is currently logged in. ( it shows active mount units for
   XDG_RUNTIME_DIR and since those have UID as name you can see who is
   logged in.
  
 
  Hmm, and `findmnt` doesn't?

 unpriv users do not have access to mount or findmount in my system, and
 for example df -h does not list them because the user is not allowed to
 get attributes of tmpfs file systems. So /run/user mounts do not show up
 in df -h


Do they have access to `cat /proc/self/mounts`?

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] grant users access to certain services only

[Mantas Mikulėnas]

On Fri, Aug 21, 2015 at 1:43 PM, Dominick Grift dac.overr...@gmail.com
wrote:

 On Fri, Aug 21, 2015 at 01:38:28PM +0300, Mantas Mikulėnas wrote:

 
  Do they have access to `cat /proc/self/mounts`?

 Ouch yes... ok that is a dead end i suppose


Right. That was my point. Restricting individual commands like `mount` is
no good if you can't restrict the actual mechanism they all use…

Mount namespaces might help here, as long as you don't use udisks/udisks2
(which, aside from leaking the same information, wouldn't even function
correctly with per-user namespaces).

[Though I don't really understand the point of hiding logged-in UIDs at
all... Isn't hidepid=2 enough?]

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Calculating Web page loads accurately with systemd-nspawn's network-veth Xorg

[Mantas Mikulėnas]

On Sun, Aug 23, 2015 at 4:58 PM, Kai Hendry hen...@webconverger.com wrote:

 Hi there,

 I've managed to get Firefox running like so:

 sudo systemd-nspawn --setenv=DISPLAY=:0 \
--setenv=XAUTHORITY=~/.Xauthority \
--bind-ro=$HOME/.Xauthority:/root/.Xauthority \
-D ~/containers/firefox \
firefox


 However I want to have network isolation so I can calculate Web page
 loads accurately. When I use --network-veth switch I get:

 Error: Can't open display: :0 type errors.

 I assume it's because Xorg can't network to my local host's Xorg server.
 Any tips how to manage this mapping?

 I  need network isolation going for accurate measurements from $(grep
 firefox /proc/net/dev), with hopefully _no Xorg traffic_ shown. :}


Try adding --bind=/tmp/.X11-unix, for the named X11 sockets.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev uaccess tag does not support hotplug for some devices

[Mantas Mikulėnas]

Well, as in the paste earlier, 73-seat-late.rules is the place where udev
actually looks at the uaccess tag and applies initial ACLs on device
connect. So all devices must be properly tagged before they reach that rule.

(Logind /also/ looks at the uaccess tag and applies ACLs independently of
udev rules, but it only does so when switching sessions; it doesn't do
anything when a new device is connected.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] grant users access to certain services only

[Mantas Mikulėnas]

On Fri, Aug 21, 2015 at 12:57 PM, Dominick Grift dac.overr...@gmail.com
wrote:

 Made a demo because i was bored:
 https://www.youtube.com/watch?v=KrK5a7D77l0

 In practice though this is probably not an option for you. It is very
 expensive. however it is (optionally) supported by systemd and i just
 wanted to counter
 the misinformation.

 i think it kind of sucks that systemctl --user list-units can be used to
 determine who is currently logged in. ( it shows active mount units for
 XDG_RUNTIME_DIR and since those have UID as name you can see who is
 logged in.


Hmm, and `findmnt` doesn't?

`systemd --user` runs with the same privileges as the user, anyway. So if
your SELinux policy is more permissive to systemd than regular programs,
it's a bit weird, not to mention possibly insecure.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user/session buses

[Mantas Mikulėnas]

Well, personally, I'd much prefer it if remote login could *attach* to an
existing local session, e.g. the way RDP / Terminal Services works on
Windows. (AFAIK a Wayland compositor *could* almost do that…)

On Sat, Aug 22, 2015 at 6:27 PM, Michał Zegan webczat_...@poczta.onet.pl
wrote:

 Ahm, I understand, Although it's actually a pitty. I believe it could be
 useful in some cases notably remote login, not quite sure though.


 W dniu 22.08.2015 o 16:58, Mantas Mikulėnas pisze:

 Well, you just wouldn't have more than one graphical session. That's part
 of the general plan afaik.

 Note that this is already half-broken, because some of those programs
 actually *expect* to be unique *per user* – e.g. dconf-daemon for writing
 to the dconf db – and having two copies of it in two sessions might be bad…

 On Sat, Aug 22, 2015, 13:36 Michał Zegan  webczat_...@poczta.onet.pl
 webczat_...@poczta.onet.pl wrote:

 Hello.

 I believe, although may be wrong, that session buses were used to
 enforce single instances of programs, like a program registered a name
 on dbus and another instance of the same program could not run.
 How would it affect user buses in case of multiple graphical user
 sessions?
 ___
 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




-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Delaying device service creation

[Mantas Mikulėnas]

Options:

- Configure it as part of ExecStart if possible.

- Configure it using a second .service unit (oneshot), and depend on that
one.

- Do something with udev to mark unconfigured devices with SYSTEMD_READY=0?
Not sure how. But if you can do this, it'll directly affect the readiness
of the corresponding .device unit.

On Tue, Jun 30, 2015, 18:37 Francis Moreau francis.m...@gmail.com wrote:

 Hi,

 I have a service 'A' which creates a device 'X' and does some
 configuring of the device. The device is created in a 'ExecStart='
 directive whereas its configuration happens during 'ExecStartPost='.

 But it seems that as soon as the device is seen by systemd, it creates
 the corresponding device service and starts all services that depeneds
 on this device.

 However this happens even if service 'A' hasn't finished to configure
 the device yet.

 I tried to add 'Before=X.device' in 'A' service file, but it doesn't
 seem to have any effects.

 Could anybody help me ?

 Thanks
 ___
 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] Errors/warnings when cloning systemd

[Mantas Mikulėnas]

On Mon, Jun 29, 2015 at 11:21 PM, Liam R. Howlett 
liam.howl...@windriver.com wrote:

 Hello,

 Since git 2.3, there have been a number of new fsck options added which
 produce issues when I clone the repository
 git://anongit.freedesktop.org/systemd/systemd

 $ git fsck --full
 Checking object directories: 100% (256/256), done.
 warning in tag 2a440962bc639c674cef95f5dee6f184c5daf170: invalid format
 - expected 'tagger' line


This is fine, old git versions (until mid-2005) used to create tags without
a 'tagger' field and you can find those everywhere including git.git itself.

error in tag e1ea4e5f1c429fbe62e76fc5b42bee32c2dcd770: unterminated
 header
 error in tag f298b6a712bbe700fe1dbac5b81cdc7dd22be26d: unterminated
 header
 error in tag 4ea98ca6db3b84f5bc16eac8574e5c209ec823ce: unterminated
 header


Also seems to be caused by old-format tags – when there was no message,
git-tag didn't write the separating empty line either.

These new tests are enabled by default when using git fsck.  I have been
 testing with git version 2.4.4.409.g5b1d901 and thought you might want
 to know so the error/warning messages can be corrected.


Not sure if it's worth fixing it, the post-clone fsck does not show such
warnings, only a full fsck does. And existing repos wouldn't fetch the
updated tags.

Though it could be done easily using
https://gist.github.com/c66d9ad2cfd1395a97fa or similar scripts.

Also note that the primary repository is at
https://github.com/systemd/systemd these days.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Nagios service fails

[Mantas Mikulėnas]

On Thu, Jul 30, 2015 at 4:20 PM, Sakhi Hadebe sa...@sanren.ac.za wrote:

 Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: *** One or more
 problems was encountered while processing the config files...


That sounds like a nagios problem?

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] in-kernel structured logging

[Mantas Mikulėnas]

On Thu, Jul 30, 2015 at 9:47 PM, Anne Mulhern amulh...@redhat.com wrote:

 Where can the support for structured logging be found in the kernel?
 It seems tricky, given the kernel's constraints, to support arbitrary
 structured logging.


It was added to kernel/printk.c in v3.5 – printk_emit() accepts an array of
key=value metadata, and printk() is a thin wrapper around that.

At the same time /dev/kmsg was added, to export the attached data and fix
various other problems which /proc/kmsg had.

https://git.kernel.org/linus/7ff9554bb578
https://git.kernel.org/linus/e11fea92e13f
https://git.kernel.org/linus/c4e00daaa96d
https://git.kernel.org/linus/3b552b92817c

Rsyslog can import the structured data from /dev/kmsg:

http://www.rsyslog.com/doc/v8-stable/configuration/modules/imkmsg.html

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Complicated SysVInit Migration

[Mantas Mikulėnas]

On Thu, Jul 30, 2015 at 9:40 PM, Lesley Kimmel ljkimme...@hotmail.com
wrote:

 All;

 I'm struggling with figuring out how to migrate some SysVInit scripts to
 systemd. Specifically, this service launches WebLogic Managed Server (Java)
 instances Let me describe the process flow of my current service to you:

 -The init service/script launches a Java process called WLST which
 executes a simple script
 -This WLST process connects to an already running Java process called the
 Node Manager and issues a start command for the application server it
 wishes to start
 -The Node Manager process executes a shell script as a subprocess. This
 shell script sets up a bunch of environment variables, etc.
 -Ultimately the shell script launches a Java process which is a child of
 the shell script.
 -When this Java process reports itself as running, the initial WLST Java
 process exits.
 -In the end the actual service/process that we started, and want to
 manage, is actually the GRANDCHILD of a completely separate process from
 the initial Java process that systemd launched. How, would systemd track
 that process?


systemd would see it as an extra process belonging to NodeManager.service,
nothing more.

If you want systemd to track it as an independent service, go back to step
#3 (where the Node Manager executes a shell script), and make that shell
script merely run systemctl start ... instead of creating the new
instance directly. (Make a template foo@.service unit for the WLMS
instances.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suggestion for a lowlevel fsnotify change daemon.

[Mantas Mikulėnas]

At first look, this seems very similar to FAM (which even supported NFSv3,
using custom notifications over SunRPC).

Later I remember GNOME replaced it with Gamin and finally with local-only
inotify inside glib/gvfs.

It might be useful to revive it, both inotify and fanotify have problems.
But I guess security would be a problem (how to determine which users may
receive which events).

-- 
Mantas Mikulėnas
On Jul 28, 2015 18:46, Stef Bon stef...@gmail.com wrote:

 Hi all,

 for some time I have been looking at the issue why fsnotify does not work
 with network filesystems and FUSE (with a shared backend).

 I've found out that changes initiated on the localhost, on the filesystem
 are supported by the fs change subsystems on Linux, and events initiated at
 the backend (from another host with network fs)  are not detected. This is
 because the filesystem are not aware a watch has been set on an inode,
 and thus cannot act on it.
 (if they act if they are aware is another question).

 I've tried to tackle this in the kernel. I've made this working with a
 FUSE:
 - when a watch is set on a FUSE fs, a message is forwarded to the
 userspace daemon containing the inode and the mask. I had to add a opcode
 FUSE_FSNOTIFY.
 - the fuse fs has to react in it, by setting a watch on the backend. I
 wrote a simple overlay fs, and setting a watch on the backend is simple
 - I had to add some calls to the fuse library to push changes to the VFS
 where there is no direct related call from the VFS. (files are added and/or
 files are changed)
 - the FUSE kernel module in VFS has to trigger fsnotify call when events
 are pushed to the VFS by the userspace daemon.

 This worked but is I think not the best way to deal with it.

 My suggestion it to write a fs notify change service which does all the
 watching for clients, like there are already services for desktops right
 now.

 This service should also work with a console app like mc, but also with
 desktop environments like Gnome and KDE.

 It should also be able to forward a watch to a filesystem like FUSE and
 cifs and nfs, so that they know a watch has been set.
 They can act then on it, by forwarding the watch to the backend. SMB does
 upport this, NFS4 also, and you can make FUSE also support it(depending the
 protocol).
 When the fs receives an event, it can send it back to the fs notify change
 service, which informs the client(s). This way the filesystem also stays up
 to date.

 To forward a watch and to read to incoming fsevents, a
 socket/filedescriptor is required. A FUSE fs can easily connect to it at
 startup, the in kernel filesystems need some extra. Via mountoptions parse
 the fd to the kernel?

 Is this something what can be added to systemd? Please let me know what
 you think of it.

 Stef


 ___
 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] working with PrivateNetwork=yes

[Mantas Mikulėnas]

systemd does not assign names to the namespaces – this is mostly an 'ip'
thing, though it has been requested for systemd earlier.

If you know a PID which is in that namespace (e.g. from 'systemctl show'),
you can use 'nsenter --net' to switch into that namespace.)

# nsenter --net --target $PID

You can also make it show up in 'ip netns' with the following:

# touch /run/netns/foobar
# mount --bind  /proc/$PID/ns/net  /run/netns/foobar

(However, if all involved services are stopped and then restarted, systemd
will not try to reuse the same netns (it doesn't care about the names), it
will just create a new one, and you'll have to re-do the above.)

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

Re: [systemd-devel] How to remove *~ journal files?

[Mantas Mikulėnas]

On Sun, Aug 9, 2015 at 9:57 AM, Andrei Borzenkov arvidj...@gmail.com
wrote:

 More than half of all files here are *~ files:

 bor@opensuse:~/src/systemd ls -1
 /var/log/journal/40527be2480f8cf60f4e8d4b06b0/*~ | wc -l
 85
 bor@opensuse:~/src/systemd ls -1
 /var/log/journal/40527be2480f8cf60f4e8d4b06b0/* | wc -l
 127

 If I understand it correctly they are corrupted files. Should not they
 have been deleted?


Well no, they still have your logs, and they're usually 99% readable.
Journald renames even uncleanly closed files to journal~, just in case.


 What is the correct procedure to remove them?


`rm`, or let journald's built-in log rotation take care of them.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Mantas Mikulėnas]

On Fri, Aug 14, 2015 at 8:42 PM, Michał Zegan webczat_...@poczta.onet.pl
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello.

 I was trying to install archlinux with linux 4.1, systemd-224 on the
 uefi machine.
 At the end of system installation, I issued bootctl install command
 from within chroot, but the command has failed because I did not have
 access to efi variables.
 After that, I have done:
 mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars (the
 mountpoint path may be wrong but you get the idea)
 And, after the next bootctl install, the system froze. I am blind and
 didn't ask anyone what happened, but I believe that the kernel panicked.
 Is this related to mounting efivarfs two times and modifying
 variables, or what? I do not have any vm to test it on, well. Can
 anyone confirm that something like that happens either normally or
 when mounting efivarfs twice?


This might be a bug in 4.1's EFI variables handling... A few people in
#archlinux, including myself, have noticed crashes if the efivars are
accessed after hibernate  resume (on first try, efibootmgr segfaults; on
second try, the kernel panics). I haven't gotten around to reporting it yet.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal log rotation notification

[Mantas Mikulėnas]

On Fri, Aug 14, 2015 at 2:20 PM, giulix giulio.marti...@gmail.com wrote:

 Hello,

 I have a process that reads from the journald log file. It gets a
 notification from inotify that something's changed, opens the journal,
 skims through it for messages it's interested in, does its stuff and closes
 the journal file (
 http://www.giulix.it/content/extracting-data-systemd-journal-programmatically
 ).
 When the journal log file is rotated, the process stops to do its job. It
 is, of course, because it never realizes the file it's waiting on for
 notifications via inotify has changed.
 I have uselessly tried to implement some mechanism to have my process
 restarted when the journal file changes, but it seems that nothing is
 available from systemd or journald to notify a process that journald is
 switching to a new output file.


There is no need for a signal – inotify can inform you about renames as
well.

But, you shouldn't reimplement the entire logic yourself. (There's more to
it, like separate systemd or user journals) *Instead, call
sd_journal_get_fd(3) and let libsystemd do the monitoring.*

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Getting EOF on FD#1 stdout (a service using socat)

[Mantas Mikulėnas]

On Mon, Jul 27, 2015 at 1:31 PM, John Lane syst...@jelmail.com wrote:

 I have a problem with what I thought would be a simple service unit:

 # /etc/systemd/system/socat.service
 [Service]
 ExecStart=/usr/bin/socat UDP-RECV:4321 STDOUT

 The expected outcome is that /usr/bin/socat UDP-RECV:4321 STDOUT is
 started with its standard output connected to the journal.

 However, the service terminates immediately without error. I've looked
 into it and notice that socat is getting an EOF on FD#1, its standard
 output, and it then terminates:

 N starting data transfer loop with FDs [5,5] and [1,1]
 N socket 2 (fd 1) is at EOF
 I close(5)
 N exiting with status 0


socat uses bidirectional streams by default, so if it says it hit EOF on
STDOUT, maybe it's treating it as alias to STDIO by default?

Try using `socat -u` for unidirectional mode.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Creation of additional links for selected devices

[Mantas Mikulėnas]

On Sun, Jul 26, 2015 at 6:50 PM, SF Markus Elfring 
elfr...@users.sourceforge.net wrote:

 Hello,

 I would like to clarify the combination of commands like
 udevadm control -p and udevadm trigger a bit more.


Hmm, I'm not sure when `control -p` could ever be useful...


 How do device properties differ from attributes in this
 use case?


Properties (sometimes called environment) are held in udev's database; they
can be set via ENV{} or imported from helpers (e.g. hwdb, blkid...).

Attributes correspond directly to files in sysfs; they can be read or set
via ATTR{}, but you're always limited to only the information exported by
the *kernel*.


 I imagine that additional properties can be set before
 a corresponding addition of matching devices would
 be triggered. Would you like to share any more experiences
 around the fine-tuning of such settings and their reuse
 for the generation of symbolic links by udev rules?


...??

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container

[Mantas Mikulėnas]

Note that devpts also supports multiple instances – the host /dev/pts is
not the same as the guest /dev/pts'en. So my guess is that your stdio is
attached to a pty from the *host*.

Not really sure how that breaks job control though.

Also, the fd symlinks are slightly magical; they can be followed and opened
even if readlink returns garbage. (For example, a socket fd or a pipe fd
wouldn't even *have* a path to return, yet the /proc symlink can be
opened.) So that again shouldn't cause problems.

On Fri, Jul 17, 2015, 11:27 Ben Gamari b...@smart-cactus.org wrote:

I have been having quite some trouble getting nspawn give me a shell
with proper job control in a CentOS 6.6 guest. The problem appears to be
that the nodes representing the std{out,err,in} fds in /proc are
malformed,

$ sudo strace -f -obad systemd-nspawn -D$(realpath centos6.5-amd64)
Spawning container centos6.5-amd64 on /home/ben/vm/centos6.5-amd64.
Press ^] three times within 1s to kill container.
Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
Read-only file system
Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
Read-only file system
/etc/localtime is not a symlink, not updating container timezone.
-bash: cannot set terminal process group (-1): Inappropriate ioctl for
device
-bash: no job control in this shell
-bash-4.1# ls -lh /proc/self/fd
total 0
lrwx-- 1 root root 64 Jul 17 04:14 0 - /7
lrwx-- 1 root root 64 Jul 17 04:14 1 - /7
lrwx-- 1 root root 64 Jul 17 04:14 2 - /7
lr-x-- 1 root root 64 Jul 17 04:14 3 - /proc/13/fd

Note that fds 0, 1, and 2 all point to a non-existent /7 file. I believe
this should instead point to /dev/pts/7, although strangely this does
not exist either despite /dev/pts being mounted. I am running a very
recent (4.1) kernel.

Am I correct in assuming that this is not expected behavior? What am I
missing here?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Confusing journal information - journal size

[Mantas Mikulėnas]

On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com wrote:


 Hi,

 I'm looking through some journals now, and even though I've seen it a
 few times I haven't thought about it until now.

systemd-journal[1151]: Runtime journal is using 8.0M (max allowed
  4.0G, trying to leave 4.0G free of 63.7G available →
  current limit 4.0G).

 Could this line be cleaned up so you don't have to look up a man page to
 try to figure out what this really means?  Here's my uneducated guess
 and confusion of this line:

 * Runtime journal is using 8.0M
   - Okay, so currently the journal uses 8MB of disk-space.  No problem.

 * max allowed 4.0G
   - Okay, so the journal should not grow beyond 4GB, makes sense.  No
 problem.

 * trying to leave 4.0G free of 63.7G available
   - Uhm, what!? So it will grow until there is 4GB left on the
 filesystem?  Not so okay.


It chooses the /smallest/ limit, not largest. (Common sense...) For
example, if you had only 5 GB space available, the journal would not grow
beyond 1 GB.


 * current limit 4.0G
   - Ehh ... okay ... so make up your mind, please!  So will the
 journal grow until 4GB or 59.7GB.


This *is* it making up its mind: min(limit 1, limit 2) → resulting limit

But then I looked into /var/log/journal ...

   # du --si -s /var/log/journal/
   4.3G  /var/log/journal/

 I do see that both system,journal and user-UID.journal are both 8.4MB,
 and from that I can guess what the log entry tried to tell me with
 Runtime journal ... but how is /that/ information useful for me, from
 a sys-admin point of view?


Runtime here means /run, as opposed to persistent in /var. They have
separately configurable limits, since /run is in RAM and /var is usually on
disk. (Though, I'm not entirely sure what purpose the runtime journal even
serves, when /var is available.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Packaging systemd user-instance service files

[Mantas Mikulėnas]

On Fri, Jul 17, 2015 at 9:38 PM, Ahmed S. Darwish darwish...@gmail.com
wrote:

 Hi everyone,

 I'm currently transforming a network daemon to become a native
 ``Type=notify'' systemd service. This daemon uses native PulseAudio
 simple APIs for output.

 Due to the PulseAudio dependency, the service needs to run under the
 user session. Otherwise, all PulseAudio APIs [e.g. pa_simple_new()]
 returns a ``Connection Refused'' error. [1]

 Given the above, I've built the following service file:

 [Unit]
 Description=AirTunes Synchronous Audio Service
 [Service]
 Type=notify
 ExecStart=/usr/local/bin/shairport-sync
 [Install]
 WantedBy=default.target

 And the following snippet in the package Makefile.am:

 cp scripts/shairport-sync.service /usr/lib/systemd/user/
 systemctl --user daemon-reload
 systemctl --user enable shairport-sync.service
 systemctl --user start shairport-sync.service


So the real problem is not that it *doesn't work*, but rather that it
*shouldn't
be done*. That makefile is mixing entirely separate things – installation
(packaging), global configuration, and per-user configuration.

(Not to mention the dangerous assumptions that 1) there's exactly one user
logged in during installation, and 2) that they'll actually want to run the
program right now...)

As you can see, the service is properly installed under
 ``/usr/lib/systemd/user/'' to run under the systemd user instance.

 Now the problem is that the Makefile commands above run as root,
 and thus all the ``systemctl --user'' commands fail with:

 Failed to get D-Bus connection: Connection refused

 So, the question is, can I start ``systemctl --user daemon-reload''
 and ``systemctl --user enable'' above in some form while the
 Makefile is run from root?


No, but you don't need to. Just install the file to /usr/lib/systemd/user,
and that's it. It'll be available to all users.

If you want to forcefully enable the service for all users, then also
symlink it into /usr/lib/systemd/user/default.target.wants/, which is
almost exactly what `systemctl enable` does (except system-wide). That'll
make it start on login for everyone.

But the general rule is, do not start user-session processes from system
tasks.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently

[Mantas Mikulėnas]

On Mon, Jul 20, 2015 at 1:14 PM, Daniel Mack dan...@zonque.org wrote:

 On 07/19/2015 11:01 AM, Namhyung Kim wrote:
  Signed-off-by: Namhyung Kim namhy...@gmail.com

 Looks good, thanks! However, it does not apply against current master.
 Care to rebase? Also, we generally prefer GitHub pull requests these
 days. And you can leave off the Signed-off-by line, we don't use that in
 the systemd project.


Does including it hurt though?

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Launching a unit when a network interface is configured?

[Mantas Mikulėnas]

On Mon, Jul 13, 2015 at 12:50 AM, Toke Høiland-Jørgensen t...@toke.dk
wrote:

 Hi

 I'm trying to port a set of traffic shaping scripts (sqm-scripts) from
 OpenWrt to Arch Linux. I would like to be able to have a systemd unit
 be run when an interface is configured (by systemd-networkd). Kinda like
 the if-up.d facility in some distros, I guess...

 I figured out that I can depend on the interface *appearing* by using

 BindsTo=sys-subsystem-net-devices-%i.device
 After=sys-subsystem-net-devices-%i.device

 ...but is there also a way to get a unit to run when an interface is
 configured?


Systemd doesn't know when an interface is /finally/ configured (e.g. maybe
the configurator added one address but is still about to add more; maybe it
added an IPv6 address but is still waiting for DHCPv4; maybe it finished
with addresses but is still configuring routes...)

So you really need this to be part of the configurator itself. As a direct
equivalent to if-up.d, NetworkManager has dispatcher.d, but
systemd-networkd doesn't yet have anything such.

However, both NM and networkd have is-online tools, for example,
*systemd-networkd-wait-online.service*, which your unit can depend on. Note
that by default it waits for *all* interfaces to be configured; if you only
need a specific one, you can create your own (instanced/templated) version
that would use --interface=%i. See also `man
systemd-networkd-wait-online`.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd services via SSH (-H key)

[Mantas Mikulėnas]

On Fri, Oct 23, 2015 at 2:11 PM, Lennart Poettering <lenn...@poettering.net>
wrote:

> On Fri, 23.10.15 14:03, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
> > On Fri, Oct 23, 2015 at 1:55 PM, Lennart Poettering <
> lenn...@poettering.net>
> > wrote:
> >
> > > On Fri, 23.10.15 00:59, Reindl Harald (h.rei...@thelounge.net) wrote:
> > >
> > > >
> > > >
> > > > Am 23.10.2015 um 00:39 schrieb Ivan Shapovalov:
> > > > >On 2015-10-22 at 23:12 +0200, Reindl Harald wrote:
> > > > >>[...]
> > > > >>and why not simply "timedatectl -H user@host[:port]" since
> host:port
> > > > >>is
> > > > >>a well known protocol agnostic way to specify a non-default port?
> > > > >
> > > > >Because the syntax of -H parameter is "[user@]host[:container]"
> > > > >and it does not allow specifying an explicit port number.
> > > >
> > > > [user@]host[:container][:port]
> > > > [user@]host[:port][:container]
> > > >
> > > > nothing unusual
> > >
> > > Nope. The idea is that
> > >
> > >   foo:bar:baz:waldo
> > >
> > > is kind of "path": connect to host "foo", enter its container "bar",
> > > and from there connect to "bar"'s container "baz" and then further
> > > down into "baz"'s container "waldo"... Containers are stackable after
> > > all.
> > >
> >
> > The usual path separator would be "/" or "!", then?
>
> I have never seen "!" for this. (or well, maybe uucp, but christ...)
>

Yeah, I was referring to UUCP, since it's the same kind of hop-by-hop
source-routing.

(Admittedly, ":" was used the same way in Berknet...)

Though, wouldn't containers just run sshd themselves? Or is this mostly for
very-lightweight things?

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] target file and executable file relationship doubt

[Mantas Mikulėnas]

On Mon, Oct 26, 2015 at 10:13 AM, kennedy <kennedy...@163.com> wrote:

> what's the relationship between the target file and the real executable
> file ?
>
> "local-fs-pre.target" ,"local-fs.target" will start which service (will
> execute which binary file) ?
>

None. They're .target units – their purpose is only to group other units.
But they don't necessarily depend on any .service unit at all – in fact
with local-fs*.target it's the opposite; *services* depend on these
targets, and the targets themselves only depend on mounts.

$ systemctl list-dependencies local-fs.target
local-fs.target
● ├─boot.mount
● ├─home.mount
● ├─tmp.mount
● └─var-lib-machines.mount

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-modules-load path

[Mantas Mikulėnas]

On Tue, Oct 27, 2015 at 10:12 AM, kennedy <kennedy...@163.com> wrote:

> where is the systemd-modules-load.service to load the .ko file path ?
>
> http://www.freedesktop.org/software/systemd/man/modules-load.d.html
>
> this example doesn't tell us where is the virtio-net.ko file.
>

modules-load.d uses the exact same locations and configuration as kmod &
modprobe:

http://man7.org/linux/man-pages/man8/modprobe.8.html

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to source a variable file using systemd

[Mantas Mikulėnas]

On Tue, Oct 27, 2015 at 12:35 PM, Soumya Koduri <skod...@redhat.com> wrote:

> Hi,
>
> We have a use-case where in we have to read an environment variable (say
> ${MY_ENV_FILE}) from a file (say /etc/myconfig) and source ${MY_ENV_FILE}
> to read yet another environment variable (say ${MY_ENV_VAR} in our systemd
> service file.
>
> I first tried out below --
>
> EnvironmentFile=/etc/myconfig
> EnvironmentFile=${MY_ENV_FILE}
> ...
> ...
> ExecStart='/bin/echo ${MY_ENV_VAR}'
>
>
> But this gave an error saying that EnvironmentFile can take only absolute
> paths. So instead I tried to find a work around and get the behavior using
> the bash script as below -
>
> EnvironmentFile=/etc/myconfig
> 
> ExecStart=/bin/bash -c 'source ${MY_ENV_FILE} && echo ${MY_ENV_VAR}'
>
>
> This doesn't throw any warnings but the ${MY_ENV_VAR} is still not read
> from the ${MY_ENV_FILE}
>

This would probably work if ${MY_ENV_VAR} was escaped (to let it be
processed by bash, not systemd).


> Kindly let me know what is the best way to read Environment variables from
> a file whose path is not fixed but yet another variable.
>

There is no such option in systemd. If you need shellscript-like features,
just run a wrapper shell script via ExecStart.


-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl suspend

[Mantas Mikulėnas]

On Wed, Nov 11, 2015 at 11:13 PM, Steve Abner <pheonix@att.net> wrote:

> I have an issue of the console not turning back on. I have a new build,
> linux 4.2, amd64, systemd, kdbus
> on a mac mini. The first try was hybrib-sleep, failed so tried suspend.
> From journalctl there seems to be
> no related errors, one:



> systemd-networkd[289]: wlan0: DHCPv4 address 192.168.1.82/24 via
> 192.168.1.254
> systemd-network[289]: segfault at 6e0063 ip 7f913210409a sp
> 7fff38450b98 error 4 in libc-2.22.so[7f9132083000+19a000]
>  or with audit enabled
> audit[269]: ANOM_ABEND auid=4294967295 uid=76 gid=76 ses=4294967295
> subj=kernel pid=269 comm="systemd-network"
> exe="/lib/systemd/systemd-networkd"
> systemd-network[269]: segfault at 6e0063 ip 7f4d2bcb909a sp
> 7ffedf852108 error 4 in libc-2.22.so[7f4d2bc38000+19a000]
>

That's an unrelated bug in networkd.


>  Once awaken from sleep, out journal to file, reboot. This regains
> console. Turning console monitor off/on
> has no effect. Also there is no dev/pts/ptmx as this is terminal only,
> working out bugs before adding


/dev/pts/ptmx *is* about terminals; it has nothing to do with graphics nor
display managers. But its primary location is just */dev/ptmx* – not all
systems have it under /dev/pts/.


> display_manager. Maybe something in lunix config is not set to work with
> systemd suspend? I know of
> modules or builds not informing about dependencies, 4-5 days of builds to
> get wifi working because of it.
>   Thanx


systemd *does not have* its own suspend mechanism, it uses only what the
kernel itself provides.

Run `echo mem > /sys/power/state`; if that doesn't work, then you have a
kernel problem.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Mantas Mikulėnas]

On Thu, Nov 12, 2015 at 7:40 AM, Matthew Hall <mh...@mhcomputing.net> wrote:

> On Thu, Nov 12, 2015 at 12:12:55AM -0500, Matthew Hall wrote:
> > /etc/udev/rules.d/70-net-names.rules:
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":00:1f.6", NAME="eth0"
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":08:00.0", NAME="eth1"
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":0a:00.0", NAME="eth2"
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEM=="pci",
> KERNELS==":0a:00.1", NAME="eth3"
>

I'm not sure if udev even still _allows_ renaming to eth*, but even if it
does, that's explicitly not supported. (For example, between the time eth0
appears and the "rename to eth1" rule gets processed, another eth1 might
also appear, and the rename would fail.) If you want custom names, use en*
or port* or lan* or some other prefix.


> For future users who hits this, I think I finally found the bug.
>
> You have to use the "SUBSYSTEMS" filter not the "SUBSYSTEM" filter. I am by
> far not an expert on udev and the rules are extremely confusing. Is there a
> better way to write this ruleset?


The way they work is simple though – they directly compare the values you'd
see in `udevadm monitor --env` or `udevadm info /sys/class/net/eth0`. If it
says "SUBSYSTEM=net", then you can match it using SUBSYSTEM=="net", that's
it.

But I guess the more important thing to know is that the network interface
is _not the same thing_ as the raw PCI device; it's shown as a sub-device
in /sys. (A single PCI device could easily expose multiple network
interfaces, for example.) Compare the output of `udevadm
info /sys/devices/pci:00/:00:1c.0/:01:00.0` vs `udevadm
info /sys/devices/pci:00/:00:1c.0/:01:00.0/net/eth0`.

That's why you use "SUBSYSTEMS=" and "KERNELS=" – you're checking
information of the _parent_ device. That said, some of the matches are IMHO
a bit redundant, and you'd be fine with:

ACTION=="add", SUBSYSTEM=="net", KERNELS==":0a:00.1", NAME="em1"

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Mantas Mikulėnas]

On Thu, Nov 12, 2015 at 9:29 AM, Matthew Hall <mh...@mhcomputing.net> wrote:

> On Thu, Nov 12, 2015 at 07:59:03AM +0200, Mantas Mikul??nas wrote:
> > I'm not sure if udev even still _allows_ renaming to eth*, but even if it
> > does, that's explicitly not supported. (For example, between the time
> eth0
> > appears and the "rename to eth1" rule gets processed, another eth1 might
> > also appear, and the rename would fail.) If you want custom names, use
> en*
> > or port* or lan* or some other prefix.
>
> Let me try and put this another way. I have been using UNIX 24 years. I
> have
> typed the characters eth0 so long that it's long since been hardcoded into
> my
> fingers; trying to change it would drive me crazy and serve no beneficial
> purpose besides confusing me when I am trying to get work done. The
> computer
> is a tool to help me solve problems. It makes more sense to get the
> computer
> to accomodate the users than the other way around.
>
> Dynamically populating the "eth*" namespace with random unexpected network
> interfaces on the fly should honestly be considered a bug not a feature. If
> they are dynamically populated then they can be placed anywhere, so why not
> place them under net0, net1, net2, etc.?
>
> It makes no sense to put them into the middle of a namespace that has
> decades
> of what had previously been pretty clear easy-to-follow traditions behind
> it.
>

...Really not sure what you're complaining about, here.

You begin with saying that eth# is good because that's how it's been done
for decades – but then you say the exact same thing is now *bad* and the
kernel should start putting new interfaces under net#, completely
contradicting your earlier "trying to change it would drive me crazy". What
even?

The kernel has been "dynamically populating the eth* namespace with random
unexpected network interfaces" since day one. It's not a systemd thing.
It's as you said "how UNIX has always worked".

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Mantas Mikulėnas]

On Thu, Nov 12, 2015 at 10:52 AM, Matthew Hall <mh...@mhcomputing.net>
wrote:

> On Thu, Nov 12, 2015 at 09:56:28AM +0200, Mantas Mikul??nas wrote:
> > You begin with saying that eth# is good because that's how it's been done
> > for decades ??? but then you say the exact same thing is now *bad* and
> the
> > kernel should start putting new interfaces under net#, completely
> > contradicting your earlier "trying to change it would drive me crazy".
> What
> > even?
> >
> > The kernel has been "dynamically populating the eth* namespace with
> random
> > unexpected network interfaces" since day one. It's not a systemd thing.
> > It's as you said "how UNIX has always worked".
>
> Yes, of course at first it appears to be a contradiction.
>
> Until you consider that for most of these decades, the software was
> populating
> more or less the same set of static devices once at boot, albeit in a
> potentially weird order. It was not randomly adding or removing things
> on-the-fly as some new driver comes up or down.
>
> So, we took was was an admittedly semi-random process that was working
> pretty
> well, and starting doing thinsg in a new way. Except this new way comes
> with
> some unpleasant side effects.
>
> This new way steals the old eth* namespace everybody was comfortable with,
> despite its issues, and makes it a lot more random and full of weird
> dynamic
> stuff. The need for weird dynamic stuff was unavoidable, but it seems
> unhelpful to complicate the problems with eth* by pouring more gasoline on
> it.
>
> Putting weird stuff in there by itself would not be a big deal. Except now
> you're saying that we are prohibited from giving meaning and lofical back
> to
> that namespace, merely because the software wants to reserve the right to
> randomly insert weird stuff into the middle of that namespace at any point
> for
> no really reason in terms of features or usability as far as I could
> determine.
>

I am _still_ not sure what you're talking about. The kernel's eth*
assignment policy hasn't changed for _many years_ – first device detected
gets eth0, second gets eth1, and so on. It has always been so.

The "new way" of systemd _does not_ use the eth* namespace for anything.
Just as you said, it uses alternative prefixes such as en* for the
"persistent" names.


-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[Mantas Mikulėnas]

On Mon, Nov 2, 2015 at 3:34 PM, Richard Maw <richard@codethink.co.uk>
wrote:

> On Mon, Nov 02, 2015 at 09:04:31AM +0100, Lennart Poettering wrote:
> > On Wed, 28.10.15 19:30, John (da_audioph...@yahoo.com) wrote:
> >
> > > I have a simple bash script that I would like to have a user service
> > > file run with an argument when the system enters a sleep or
> > > hibernation state but as I understand it, user service units do not
> > > use the sleep.target.  The goal is to have the following run before
> > > the system goes into sleep/hibernate triggered by whatever mechanism
> > > systemd uses to detect when the user sleeps or hibernates the
> > > system: '/usr/bin/psd sync'
> >
> > You can install a suspend delay inhibitor:
> >
> > https://wiki.freedesktop.org/www/Software/systemd/inhibit/
> >
> > That works from privileged code the same as for user code. However,
> > you cannot really do that from shell code. I fear for shell this is
> > simply not available, sorry.
>
> You may be able to abuse the hell out of systemd-inhibit to have it work:
>
> #!/bin/sh
> # Approach cribbed from http://www.opopop.net/Harnessing_DBus/


Might as well use ctypes.sh then... Or a more capable language:

https://gist.github.com/grawity/a10ee46d7ff58048d483

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] about libmount

[Mantas Mikulėnas]

On Thu, Nov 5, 2015 at 8:03 AM, yan...@iscas.ac.cn <yan...@iscas.ac.cn>
wrote:

> hi guys
> I try to build the Systemd219 and get this "
> configure: error: *** libmount support required but libraries not found"
>  what I  do  is “./configure”  and when I use "dpkg -s libmount " ,I get
> this "Source: util-linux
> Version: 2.25.2-4ubuntu3" . So   where is the problem? thanks!
>

You'll need the development headers, "libmount-dev" package.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting nmb.service from within a program

[Mantas Mikulėnas]

On Tue, Nov 3, 2015 at 9:44 PM, Paul D. DeRocco <pdero...@ix.netcom.com>
wrote:

> I have a Yocto embedded system running a simple Samba 4 server, using
> systemd. I'm relying on the system hostname being the default netbios
> name, and I need to be able to change the hostname, and therefore the
> netbios name, from within my main application. I write the new hostname to
> /etc/hostname, and also call sethostname(), but in order for the change to
> take effect, the nmbd daemon (that is, nmb.service) needs to be restarted.
>
> Since systemd is managing this service, it seems I should be accomplishing
> this by telling systemd to restart the service. Is there a documented way
> to do this from within a program? There must be some way, since systemctl
> does it.
>

Pretty sure it's documented:

http://www.freedesktop.org/wiki/Software/systemd/dbus/

http://www.freedesktop.org/wiki/Software/systemd/hostnamed/

and so on.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] detect-virt: detect in best-heuristic order

[Mantas Mikulėnas]

On Wed, Nov 4, 2015 at 3:52 PM, Lennart Poettering <lenn...@poettering.net>
wrote:

> On Wed, 04.11.15 15:54, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
> > 04.11.2015 00:04, Andrew Jones пишет:
> > >afaict, this will fix a regression caused by commit 75f86906c5.
> > >Where we used to report "kvm" before that patch, without this patch,
> > >we would only report "qemu".
> >
> > Are you sure it is regression? QEMU is a program (platform) while KVM is
> > technology. Modern VirtualBox can use KVM as PV interface but it still
> > remains VirtualBox. QEMU may use KVM as PV interface but it still remains
> > QEMU.
> >
> > Where does it matter? Is anything broken because of this change?
>
> I am pretty sure that vbox should be reported as vbox even if it uses
> kvm as backend. qemu-kvm should be reported as kvm, and any other qemu
> as qemu.
>

As I understand it, VirtualBox doesn't use KVM as *backend*; it only
exposes a KVM-like paravirt interface to *guests*.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] ip forwarding

[Mantas Mikulėnas]

On Fri, Nov 6, 2015 at 11:09 AM, Reindl Harald <h.rei...@thelounge.net>
wrote:

>
>
> Am 06.11.2015 um 08:11 schrieb Johannes Ernst:
>
>> This makes my point. The default = 0 is counter intuitive and costs much
>> time for the lucky ones among us who can figure it out. The rest will just
>> give up...
>>
>
> defaults should have security in mind, most setups don't need it enabled
> and the ones which will just give up don't understand what they are doing
> anyways and so bette don't mess with it
>

The _kernel_ default is also 0 anyway, for both global and per-interface
settings.

The problem is that now you cannot _enable_ it via the usual routes
(sysctl) anymore, because networkd mindlessly overrides that. As a
long-time sysadmin, surely you wouldn't like your explicit configuration
having been broken that way?

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fix for - udev/ata_id failing on SATA drives behind JMicron USB bridge

[Mantas Mikulėnas]

On Fri, Oct 16, 2015 at 5:44 AM, Harendra Kumar <harendra.ku...@gmail.com>
wrote:

> In fact I tried to find that information on github before sending this
> email. The 'Blame' tab on github showed only a refactoring change touching
> these lines of code. Also, the file seems to have been imported from
> elsewhere in github and it seems github does not seem to know the history
> before the import. I am not a git expert - maybe I could use some git
> commands in my cloned repository to find that info - will have to dig more
> on that unless someone here can give me a pointer on how to find it.
>

Try `tig blame src/udev/ata_id/ata_id.c`, it follows renames and you can
jump to an older commit using , and back using <

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl edit via polkit results in access denied

[Mantas Mikulėnas]

On Fri, Oct 16, 2015 at 5:44 PM, Chris Bell <cwb...@narmos.org> wrote:

> Hello,
>
> I have configured polkit to allow my user to manage basically everything
> in systemd without requiring sudo or root. Enabling, disabling, reloading,
> etc all work as expected. However, 'systemctl edit' does not. It does not
> deny permission for me to use the function, but it fails when trying to
> copy the file to a temporary directory:
>
> $ systemctl edit rngd.service
> Failed to create directories for
> "/etc/systemd/system/rngd.service.d/override.conf": Permission denied
>
>
> Is there a way for polkit to correct or temporarily override these
> permissions? Or should I use ACLs to grant write permission to my user for
> those directories?
>

The problem is that `systemctl edit` only uses D-Bus calls for reloading
systemd; it still manages the unit files directly. For now, use directory
ACLs.

(Wonder if this could somehow make use of GNOME's new admin:/// vfs...)

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] SMACK runtime vs build-time checks? (aka: tmp.mount broke my boot)

[Mantas Mikulėnas]

So far all existing SELinux and SMACK options had runtime checks – if
systemd was built with +SMACK but the kernel wasn't, it still worked fine.
(Arch uses such a configuration.)

But then https://github.com/systemd/systemd/issues/1571 added an option to
tmp.mount which only depends on the build-time option, which creates
problems when booting a non-SMACK kernel...

Any ideas on how to fix it? All previous such fixes were for API
filesystems in mount-setup.c and could do flexible checks, but that clearly
won't work for mount units.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd

[Mantas Mikulėnas]

On Fri, Oct 9, 2015 at 1:22 PM, Reverend Homer <mk.43.e...@gmail.com> wrote:

> Hi,
>
> 09.10.2015 11:45, yan...@iscas.ac.cn пишет:
>
>>
>> Hello guys:
>>  I have a question. If I want use systemd in my system,like mint 17
>> ,what should I do?
>>
> Please, don't use devel mailing list for such questions.
>

It's also a tech support list.


> If you want to install systemd on linux mint, you should do something like
> this:
> http://superuser.com/questions/917804/switching-to-systemd-on-linux-mint


It's Debian-specific; I'm not sure if Mint has imported all the changes...

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

[Mantas Mikulėnas]

On Thu, Nov 12, 2015 at 8:13 PM, Matthew Hall <mh...@mhcomputing.net> wrote:

> On Thu, Nov 12, 2015 at 10:37:56AM +0100, Lennart Poettering wrote:
> > Since time began eth* is where the kernel automatically picked iface
> > names from. If you want to assign your own names go for some other
> > namespace, or be prepared to race against the kernel, and deal with
> > it.
> >
> > Lennart
>
> Again, this logic worked well when the level of dynamism was lower.
>
> But now the level of dynamism is higher and different principles should
> apply.
>

And systemd is the cause of that dynamism how exactly? If you're
complaining that the kernel started probing & detecting devices in a less
stable order, then you're complaining in very much the wrong place (and
maybe during the wrong decade).

The two times udev was involved in network interface naming, it was to make
the names _more stable_, not less. Perhaps your earlier systems had an
autogenerated .rules file which would make the names static – this was
implemented via udev (though I don't remember if it was Debian-specific or
upstream). Fedora for a while used "biosdevname" to make the names static –
this was also implemented via udev. And so on...


> You aren't thinking very much about how it will work for newer users.


Well, you've been using UNIX for 24 years, you're not exactly a "newer"
user...

And new users don't have any problems with the enp* scheme (probably
because they _aren't_ used to eth*) – they see enp1s0, wlp2s0 in `ip link`
and they successfully use those.

~

Either way, I remain convinced that you have not the slightest idea what
you're talking about.

You say, "This new way steals the old eth* namespace everybody was
comfortable with, despite its issues, and makes it a lot more random and
full of weird dynamic stuff.", even though this "new way" is the _exact
opposite_ of that.

The "persistent naming" that you linked to _does not_ use the eth*
namespace for anything, nor does it use random names anywhere – it
specifically avoids that, using enp* prefixes and PCI-based names. You've
been ranting all this time about entirely irrelevant things.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] bootctl: default mount point for the ESP partition.

[Mantas Mikulėnas]

On Tue, Sep 1, 2015 at 7:47 PM, Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> On 01/09/15 17:21, Goffredo Baroncelli wrote:
> > I discovered that bootctl assume as default mount point for the ESP
> > partition the /boot directory. Instead it seems to me that the most part
> > of distributions prefers /boot/efi.
>
> For some context, the reasoning for /boot/efi is:
>
> In some distributions (presumably including the (Fedora-based?) ones
> where this feature was developed), /boot is traditionally treated as
> mutable and unpackaged, like /var; so the packages include the kernel in
> /usr or /lib or something, and copy it into /boot. The cost of this is
> one extra copy of the kernel on-disk, which used to be a significant
> amount of space, although on modern disks it doesn't really matter.
>
> In other distributions (like Debian and its derivatives), the OS
> packages for kernels traditionally include /boot/vmlinux-whatever and
> /boot/config-whatever as packaged files; the corresponding initramfs is
> generated at install time and placed alongside them. In these
> distributions, there is no second copy of the kernel in /usr or /lib.
> This saves some space, although, again, the amount of space saved is
> negligible on current hardware.
>
> On BIOS systems, either way was fine, because /boot was either part of
> the root filesystem, or a separate small ext2 partition near the
> beginning of the drive (to work around BIOS disk-addressability
> limitations) for use by lilo or grub or whatever. Similarly, on non-x86,
> the bootloader would traditionally either load the kernel from a
> non-filesystem like a raw flash partition, or from the root filesystem
> or a separate /boot partition; either would be fine.
>
> However, it starts to matter with the move to EFI (on x86 and
> elsewhere), or on non-EFI systems where the bootloader also reads a FAT
> partition (such as the Raspberry Pi). If the OS packages for kernels
> include files in /boot, then having a non-Unix filesystem for /boot
> becomes a problem, because the package manager (e.g. dpkg) can't use the
> same hardlink-based atomic-overwrite that it would use for robustness on
> a proper Unix filesystem. The ESP is FAT, which is not a full Unix
> filesystem, so you can't do that sort of thing. That's why Debian and
> its derivatives mount the ESP at /boot/efi instead of /boot, and why
> <http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/> mounts the
> ESP-equivalent at /boot/firmware.
>
> AIUI, /boot/efi also makes it a bit easier to have the ESP remain
> unmounted or read-only when not in active use, which is good for its own
> robustness; a system crash corrupting an unmounted partition is less
> likely than corrupting a mounted filesystem.
>

Though, why would a partition get corrupted, if it wasn't being written to
/during/ the crash?...

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [udev] Limitation of capturing remove events?

[Mantas Mikulėnas]

On Tue, Sep 1, 2015 at 6:32 AM, Tom Yan <tom.t...@gmail.com> wrote:

> Is it a limitation or bug that I can only capture remove events with
> purely SUBSYSTEM or KENREL match, but not with ATTR{*} or even DRIVER?
>

AFAIK, the former two come from the uevent itself, but the latter are
always read from sysfs... and during a remove event, the device is not in
sysfs anymore.

(Even more, some sysfs attributes might themselves query data directly from
the device, which wouldn't work well if the device is no longer connected.)

So IMHO you should match on udev's ENV{} instead, and cache the desired
attributes into ENV.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to set time from Perl

[Mantas Mikulėnas]

On Mon, Sep 7, 2015 at 5:23 PM, Manuel Reimer <manuel.s...@nurfuerspam.de>
wrote:

> Hello,
>
> if I run the following code on an intel based platform, then I don't have
> any problems:
>
>   use Net::DBus;
>   my $bus = Net::DBus->system();
>   my $logind = $bus->get_service('org.freedesktop.timedate1');
>   my $manager = $logind->get_object('/org/freedesktop/timedate1',
> 'org.freedesktop.timedate1');
>   $manager->SetTime($time * 100, 0, 0);


On 32-bit systems you may need to "use bigint;" for integers larger than
0x7fff. (Possibly also explicitly pass the value as a dbus_int64()...)

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What's mounting this partition?

[Mantas Mikulėnas]

On Sat, Sep 26, 2015 at 2:27 PM, Lennart Poettering <lenn...@poettering.net>
wrote:
>
> I think some distros (Ubuntu? Debian?) patch udisks to mount removable
> media to /media, because they ignore the DoS vulnerability that is
> using a shared namespace for such mounts. Maybe you have udisks
> installed from one of those distros?
>

udisks v1 used to do that by default, and is still installed in some
places. (e.g. udiskie probably still depends on it?)

udisks v2 also has an option (controlled through an udev property,
ENV{UDISKS_FILESYSTEM_SHARED}) to do the same.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] suspend/resume hooks, the right way

[Mantas Mikulėnas]

On Fri, Sep 25, 2015 at 11:17 PM, Łukasz Stelmach <stl...@poczta.fm> wrote:

> [1]
> http://people.skolelinux.org/pere/blog/The_life_and_death_of_a_laptop_battery.html
> [2] https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks


Aside: Doesn't upower already log that information? (/var/lib/upower)

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to bind to other drivers using systemd

[Mantas Mikulėnas]

I wonder if this could be handled with a generic Type=oneshot,
ExecStart=driverctl bind foo...

-- 
Mantas Mikulėnas
On Sep 28, 2015 21:48, "Flavio Leitner" <f...@sysclose.org> wrote:

> On Mon, Sep 28, 2015 at 08:06:50PM +0200, Kay Sievers wrote:
> > On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner <f...@sysclose.org>
> wrote:
> > > I am looking for guidance on how to properly resolve driver binding
> > > with systemd (which seems to me the best place to do that).
> >
> > This seems to be a too exotic and niche use case, nothing
> > general-purpose enough to implement high-level knobs in systemd.
>
> These alternative drivers might be new yet, so there is no much around
> them, but we need to start right to avoid problems in the future.
>
> Accelerated userspace datapath is one use case that changes the default
> NIC driver to UIO or VFIO driver. Then you use DPDK applications for
> fast packet processing or use DPDK integrated Open vSwitch for switching.
>
> Consider that Open Stack (WIP), Open Shift and maybe containers can use
> the above setup, so isn't really a niche use case.  It's pretty much a
> requirement for NFV projects as well.
>
> > As you mention, you could use custom udev rules to actually bind a
> > specific driver. I don't think we want anything more abstract in
> > systemd.
>
> The problem with that is we can't stop the service to roll back the
> driver.  Or more importantly, create a dependency to, let's say,
> start Open vSwitch only after the ports are bound to the right driver.
> Or start an application that requires the NIC to be bound first.
>
> Thanks,
> fbl
>
> ___
> 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] /etc/dbus-1/session-local.conf

[Mantas Mikulėnas]

Also this is not the path used by most software, anyway; the user bus is
expected at %t/bus, not %t/user_bus_address. I think it was moved in v205
or v215.

On Mon, Oct 5, 2015, 07:03 Mantas Mikulėnas <graw...@gmail.com> wrote:

> You normally shouldn't need to do this. For user bus, the address is
> configured in dbus.socket; for session buses it is passed as command line
> option.
>
> On Sun, Oct 4, 2015, 21:40 arnaud gaboury <arnaud.gabo...@gmail.com>
> wrote:
>
>> As I am trying to improve my knowledges in how dbus work, I discovered
>> this file in /etc/dbus-1/session-local.conf
>> 
>> 
>>   unix:path=/run/user/1000/dbus/user_bus_socket
>> 
>> --
>>
>> I Can't remember editing it, but I must have done it.
>>
>> I understand it overrides settings in /usr/share/dbus-1/session.conf
>>
>> In my case, it is correct as my session dbus socket is indeed in the
>> above path, thus override
>> unix:tmpdir=/tmp in /usr/share/dbus-1/session.conf.
>>
>> Now I am wondering this: I am user 1000 and almost the only one user
>> of the machine. But what if another user log in? In this case, the
>> path will be somewhere else.
>> Does this file recognize environment varaibles like  ${XDG_RUNTIME_DIR } ?
>>
>> Thank you for tips.
>> --
>>
>> google.com/+arnaudgabourygabx
>> ___
>> 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] /etc/dbus-1/session-local.conf

[Mantas Mikulėnas]

You normally shouldn't need to do this. For user bus, the address is
configured in dbus.socket; for session buses it is passed as command line
option.

On Sun, Oct 4, 2015, 21:40 arnaud gaboury  wrote:

> As I am trying to improve my knowledges in how dbus work, I discovered
> this file in /etc/dbus-1/session-local.conf
> 
> 
>   unix:path=/run/user/1000/dbus/user_bus_socket
> 
> --
>
> I Can't remember editing it, but I must have done it.
>
> I understand it overrides settings in /usr/share/dbus-1/session.conf
>
> In my case, it is correct as my session dbus socket is indeed in the
> above path, thus override
> unix:tmpdir=/tmp in /usr/share/dbus-1/session.conf.
>
> Now I am wondering this: I am user 1000 and almost the only one user
> of the machine. But what if another user log in? In this case, the
> path will be somewhere else.
> Does this file recognize environment varaibles like  ${XDG_RUNTIME_DIR } ?
>
> Thank you for tips.
> --
>
> google.com/+arnaudgabourygabx
> ___
> 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 and hostname supplied by DHCP

[Mantas Mikulėnas]

On Mon, Oct 5, 2015 at 9:28 AM, Alessio Igor Bogani <
alessioigorbog...@gmail.com> wrote:

> Hi,
>
> On 3 October 2015 at 15:34, Lennart Poettering <lenn...@poettering.net>
> wrote:
> [...]
> > Well, we need some kind of policy framework in place there that allows
> > the "systemd-networkd" user to set the hostname. If you disable
> > PolicyKit you have none, and hence the permission is denied.
>
> So I'll install polkit. The only downside is that polkit drag
> Javascript interpreter in which isn't a typical package for an
> embedded system due it's footprint but I suspect that I should live
> with it.  :-)
>

While I'm not really comfortable suggesting this, old polkit versions
(v0.105 and earlier) used a different rules format without JavaScript.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] startxfce4 vs logind

[Mantas Mikulėnas]

On Sun, Sep 20, 2015 at 1:05 AM, Dimitri John Ledkov <
dimitri.j.led...@intel.com> wrote:

> Heya,
>
> I boot to tty1, and login as my normal user account.
>
> Session c1, is active and has type tty. And I can access devices which
> are marked as uaccess.
>
> Then I do $ startxfce4 -> which starts graphical interface. However,
> at that time I "loose" the logind session. No new sessions are
> started, session c1 is "Active=no" & "State=online" and i cannot
> access uaccess devices any more.
>
> Both startxfce4 and systemd are compiled without policykit support (no
> idea if this matters).
>
> What I am doing wrong? Should I go talk to xfce4 people?
>
> My expectation was for a new session c2 to be started and switched to,
> type graphical, online and active. Whilst keeping c1 tty session
> online and in-active.
>

That was possible with ConsoleKit, but logind does not allow nested
sessions this way.

Instead, you can keep session c1 active by starting Xorg on the *same* tty.
Modern startx should do this automatically; earlier you had to modify your
.xserverrc like this:

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/xserverrc?h=packages/xorg-xinit=37b4597466e99667ba6035854b3386a2ee83e563

(note this is no longer present in Arch's xinit as it has been moved to
startx itself)

I don't know how startxfce4 launches Xorg, though, but you could just use
startx for it (i.e. start "startxfce4" from your .xinitrc).

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Mantas Mikulėnas]

On Wed, Sep 23, 2015 at 5:20 PM, Luca Bertoncello <
l.bertonce...@queo-group.com> wrote:

> Hi list!
>
> I'm new here and I hope, I'm in topic... I don't want to develop system,
> but I didn't found a "system-user"-ML...
>

Yeah, systemd-devel is still also the tech support list.


> So, to my problem:
> I need a possibility to call a script on shutdown/reboot/halt (I use
> CentOS 7). This **MUST** be the first one be called, since it needs many
> other service to be running...
>

Almost always, being "first" is a made up requirement. The actually
important part here is "it needs many other services" – and you probably
know /which/ specific services it needs, so you can declare them as
dependencies in your unit. *(Sometimes takes some trial and error
though...)*

In systemd, the shutdown order is generally inverse of the boot order – if
a unit has "After=X", it will be started after X, but stopped before X. So
your unit should have a Requires= (or Wants=) plus an After= for every
service it actually needs.

Also – the unit seems more like a Type=oneshot, not a Type=simple.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Mantas Mikulėnas]

On Thu, Sep 24, 2015, 09:40 Luca Bertoncello 
wrote:

> Hi Lennart,
>
> thank you for your answer!
>
> > There is no concept of "first" or "last" in systemd, since it's not
> clear what
> > that's supposed to mean if there are multiple, and what happens if some
> > operation results in activation?
>
> That's bad... :)
>
> > Hence, simply order your service against the services it requires. If
> you want
> > to just run some code when shutting down, make it a service with
> > Type=oneshot and RemainAfterExit=yes, give it an empty ExecStart=, but
> > specify ExecStop= to whatever it's supposed to do. Then order it *after*
> the
> > services that it shall be able to use, as the shutdown order in systemd
> is
> > always the inverse of the startup order, and what you specify via After=
> and
> > Before= specifies the startup order.
>
> Well, this is what I tried for more the three days... :(
> I know, that the script need at least vdsmd.service, vdsm-network.service
> and libvirtd.service.
> But it needs that the tmpfs-partition /run is mounted, too.
> I didn't found any service or target that mount/unmount /run. How can I
> specify it?
>

Well it's not a target nor a service – it's a mount. Therefore
"Requires=run.mount".

However /run will always be available on systemd systems, anyway. (That's
basically the whole point of /run…)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to automount

[Mantas Mikulėnas]

> I don't think there's any way to have
something auto-unmount

There certainly is – udev has been unmounting unplugged drives for many
years. It's done by default.

On Mon, Sep 21, 2015, 23:10 Paul D. DeRocco  wrote:

> > From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com]
> >
> > I am not sure if automount is really the right way to go. In the end,
> > your automount path will fail if your device is not plugged in.
>
> A little experimenting showed you're right.
>
> > You could always use udev rules (ENV{SYSTEMD_WANTS}='media-ext.mount')
> > to mount the volume.
> > http://www.freedesktop.org/software/systemd/man/systemd.device.html
>
> I was thinking about udev, too, but I don't think there's any way to have
> something auto-unmount. But I'm overcomplicating things. In my system, the
> only accesses made to this external flash drive are in response to a user
> command. So the simpler solution is just to have my application mount and
> unmount the drive, instead of trying to get the operating system to do it.
>
> --
>
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.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] How to automount

[Mantas Mikulėnas]

On Tue, Sep 22, 2015 at 7:38 AM, Paul D. DeRocco <pdero...@ix.netcom.com>
wrote:

> > From: Mantas Mikulenas [mailto:graw...@gmail.com]
> >
> > > I don't think there's any way to have something auto-unmount
> >
> > There certainly is - udev has been unmounting unplugged
> > drives for many years. It's done by default.
>
> Sure, you can get it to unmount after you've removed it, but that's too
> late if you haven't synced it. You have to do an explicit sync in advance
>

Well you said:

> and unmounted when I unplug it.

Are you asking the OS to be prescient?


> to avoid data loss. The only alternative is to disable write buffering,
> which makes things slow, and stresses the drive.
>

No, that's not the only alternative – making the OS flush data more often
is another, e.g. as Windows does (every 2s), and AFAIK Linux has also
started doing so somewhere in the 3.x series.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

On Tue, Dec 8, 2015 at 5:04 AM, <ni...@jurinovic.com> wrote:

> On Monday, December 07, 2015 11:28:54 PM you wrote:
>
> > It might be clearer if you described how exactly the daemon is started
> and
>
> > which cgroup it runs under (according to systemd-cgls). Perhaps you're
>
> > starting it directly from the shell, and not via systemctl as intended?
>
> >
>
>
>
> Oracle (database and listener) is started in two different ways:
>
>
>
> 1. Via root console executing the command:
>
>
>
> # su - oracle -l -c '${ORACLE_HOME}/bin/dbstart'
>
>
>
> If Oracle is started in this way, the processes 'systemd (oracle)' and
> '(sd-pam) (oracle)' DO NOT appear. And that's the problem. Seems that
> oracle daemon cannot live without these processes and it dies (shutdown by
> itself) very soon (after 5-15 minutes working). The lack of these processes
> is the cause of the crash here.
>
>
>
> 2. By logging in directly as 'oracle' user to console (tty). In this case
> the processes 'systemd (oracle)' and '(sd-pam) (oracle)' appear immediately
> after logging to console. The database and listener is then started
> executing 'dbstart' from console. This way Oracle never crashes, except if
> I deliberately kill the two processes as root during the session and Oracle
> crashes immediately.
>

I see. This doesn't kill Oracle by itself, however, it still can cause
various other problems. You really should launch daemons through a systemd
.service, Oracle is no exception.

> The "systemd --user" process is meant for interactive users (as in, not
>
> > system accounts) – it acts as the user's personal service manager. I
> don't
>
> > think lack of that process is the cause here, maybe an effect instead –
>
> > killing it is part of logind's cleanup when a user logs out.
>
>
>
> No, the lack of these processes is the cause of the crash, as I already
> said above. So far as these processes are running, no fear of Oracle's
> crash.
>

Correlation does not imply causation. These processes do nothing relevant
by themselves; their presence only indicates that a systemd-logind _user
session_ exists, which is the cause.

> What uid does "oracle" have – is it within the system account range
>
> > (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> which
>
> > would mean systemd-logind would clean up various things like IPC on
>
> > logout... (see logind.conf)
>
>
>
> [root@proton ~]# id oracle
>
> uid=54321(oracle) gid=54321(oinstall)
> groups=54321(oinstall),54322(dba),54323(oper),54324(backupdba),54325(dgdba),54326(kmdba),54327(asmdba)
>

Ok, so the UID is the problem. (These look suspiciously like made-up
numbers, but I'm guessing they are centrally-managed accounts, maybe NIS or
LDAP.)

So, since "oracle" has an UID ≥ 1000, and since you probably cannot change
that, you should instead *disable RemoveIPC= in /etc/systemd/logind.conf*
to disable the automatic IPC cleanup.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd shutdown: switch-root after remounting root fs ro

[Mantas Mikulėnas]

On Dec 8, 2015 12:13, "Radoslaw Kamil Ejsmont" <rados...@ejsmont.net> wrote:
>
> Hi,
>
> I am new to systemd. I am currently running Ubuntu 15.04 with ZFS. I
would like to switch root filesystem to a tmpfs during system shutdown to
reset root ZFS mount point (to dual boot FreeBSD). I have
used /lib/systemd/system-shutdown/foo script. I have tried using systemctl
switch-root, but the dbus daemon is already killed at this point.

systemctl wouldn't work anyway as systemd is not running anymore at that
point – during shutdown it replaces itself with a small tool whose only
purpose is to bring down whatever remains.

However, it already has the feature you need. If systemd-shutdown finds
/run/initramfs at the end, it will automatically switch to that as the new
root and launch /run/initramfs/shutdown.

For distros using dracut as initramfs, ZoL already has some support for
this:

https://github.com/zfsonlinux/dracut/blob/master/modules.d/98systemd/dracut-shutdown.service.8.asc

http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

(Hmm, wonder if Inbox's "Undo send" works or if I ended up spamming the
list...)

On Dec 8, 2015 00:19, "Niksa Jurinovic" <ni...@jurinovic.com> wrote:
>
> Hello,
>
> I am new to systemd init system as well as to fresh installed Fedora 23
> Server, and I would like to put a question related to 'systemd (user)'
> and '(sd-pam) (user)' processes invoked under each and every one user's
> login shell. The first process is '/usr/lib/systemd/systemd --user' with
> PPID=1 and the second is its child process '(sd-pam)'.
>
> What do these processes exactly do and why does my Oracle 12c
> database instance (started by 'oracle' user) always crash (silently
> shutdown by itself) WITHOUT these processes (or if they are killed)?
> When it happens, the database instance is down, and the oracle alert.log
> shows semaphore memory corruption:

It might be clearer if you described how exactly the daemon is started and
which cgroup it runs under (according to systemd-cgls). Perhaps you're
starting it directly from the shell, and not via systemctl as intended?

The "systemd --user" process is meant for interactive users (as in, not
system accounts) – it acts as the user's personal service manager. I don't
think lack of that process is the cause here, maybe an effect instead –
killing it is part of logind's cleanup when a user logs out.

(There is one --user instance for every user, shared across multiple login
sessions, so it is run under a separate "PAM session" of its own; sd-pam is
just a helper process for that.)

What uid does "oracle" have – is it within the system account range
(usually 1–999) or user account (1000–)? I wonder if it's the latter, which
would mean systemd-logind would clean up various things like IPC on
logout... (see logind.conf)

In fact I'm pretty sure that's the case according to the "Identifier
removed" error.

User accounts should be created with "useradd -r" if they're meant for
daemons, to make them have a system UID and let systemd distinguish from
personal accounts.

> ORA-27300: OS system dependent operation:semctl failed with status: 22
> ORA-27301: OS failure message: Invalid argument
> ORA-27302: failure occurred at: sskgpwrm1
> ORA-27157: OS post/wait facility removed
> ORA-27300: OS system dependent operation:semop failed with status: 43
> ORA-27301: OS failure message: Identifier removed
> ORA-27302: failure occurred at: sskgpwwait1
> ksmsdes: Error destroying SGA
> Instance termination got error 27120 from SGA destruction.
>
> If these processes are active for 'oracle' user, Oracle instance never
> crashes.

Pretty sure these processes being active is a result, not cause.

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

Re: [systemd-devel] logind's .PowerOff and .Reboot methods doesn't seem to respect inhibitors

[Mantas Mikulėnas]

On Wed, Dec 9, 2015 at 10:20 PM, Troels Mæhl Folke <
t.r.o.e.l.s@gmail.com> wrote:

> Hello,
>
> I've had problems getting systemd-logind to respect shutdown inhibitors
> when
> I ask it over DBus to power off or reboot.
>
> Here is what I've tried:
>
> In one gnome-terminal as non-root, I type:
>
> systemd-inhibit --what=shutdown --mode=block --who=unison unison-gtk2
>
> ...to set up the inhibitor.
> Then next, in another gnome-terminal - also as non-root - I type:
>
> busctl call org.freedesktop.login1 /org/freedesktop/login1 \
> org.freedesktop.login1.Manager PowerOff b true
>

AFAIK, inhibitors from the same user are ignored (which to be honest makes
them not very useful), and systemctl merely checks them manually.

(You might find gnome-session-inhibit useful; it tells GNOME itself to
avoid shutting down.)

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mounting a partition at the *right* time

[Mantas Mikulėnas]

On Mon, Jan 4, 2016 at 1:26 PM, Rainer Dorsch <m...@bokomoko.de> wrote:

> Hi,
>
>
>
> I am facing an issue with a .mount unit file. The task is simple: mount a
> partition at the *right* time.
>
>
>
> The system is OpenElec 6.0, which is based on CoreOS. /etc/fstab is on a
> squashfs, i.e. it cannot be easily modified and is empty:
>
>
>
> OpenELEC:~/.config/system.d # cat /etc/fstab
>
> OpenELEC:~/.config/system.d #
>
>
>
> I would like to mount /storage/.kodi/.local/storage/sdcard after /storage
> is mounted and before systemd-tmpfiles-setup.service starts executing:
>
>
>
> I created this .mount unit file:
>
>
>
> OpenELEC:~/.config/system.d # cat
> storage-.kodi-.local-storage-sdcard.mount
>
> [Unit]
>
> Description=sdcard mount script
>
>
>
> #Requires=storage.mount
>
> #After=storage.mount
>
> ConditionPathExists=/storage/.kodi/.local/storage/sdcard
>
>
>
> Conflicts=umount.target
>
> Before=umount.target systemd-tmpfiles-setup.service
>
>
>
> [Mount]
>
> What=/dev/mmcblk0p1
>
> Where=/storage/.kodi/.local/storage/sdcard
>
> Options=
>
> Type=ext4
>
>
>
>
>
> [Install]
>
> WantedBy=local-fs.target
>
>
>
Having no CoreOS experience, is "~/.config/system.d/" something specific to
OpenELEC? I hope you are not trying to use systemd's own ~/.config/systemd/
here, as that just plain doesn't make sense. (The main init system will not
look in each user's homedirs, and the per-user instances do not have mount
privileges...)

Can you check the output of `systemctl status
storage-.kodi-.local-storage-sdcard.mount`?

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] empty a directory in service file as ExecStartPre

[Mantas Mikulėnas]

ExecStart does not go through a shell, so it won't expand wildcards.

Try running 'find /dir -mindepth 1 -delete', that also cleans up dotdirs.

Alternatively 'sh -c "rm .../*" to handle wildcards.

On Sat, Jan 2, 2016, 13:39 arnaud gaboury  wrote:

> I can't manage to empty a directory as a Exec in a service file. Here is
> part:
>
> ---
> [Service]
> User=postgres
> Environment=REPORTDIR=/storage/psqlReport
> ExecStartPre=/usr/bin/rm -f ${REPORTDIR}/*
> ExecStart=MyCommand
>
> --
>
> $ journalctl -xe -l
> ---
> -- Unit pgcluu_collectd.service has begun starting up.
> Jan 02 12:34:02 poppy pgcluu_collectd[21593]: *** pgcluu_collectd v2.4
> (pid:21593) started at Sat Jan  2 12:34:02 2016
> Jan 02 12:34:02 poppy pgcluu_collectd[21593]: Type Ctrl+c to quit.
> Jan 02 12:34:02 poppy pgcluu[21594]: FATAL: output directory
> /storage/psqlReport is not empty. at /usr/bin/pgcluu line 1033.
> Jan 02 12:34:02 poppy systemd[1]: pgcluu_collectd.service: Control
> process exited, code=exited status=2
> -
>
> Running manually the rm command as user postgres empty the directory,
> but when in service file, the directory is still full. I see it as
> ExecStart=MyCommand complains the directory is full and service exits
> with an error.
> User postgres has of course rw access to directory content.
> No any kind of interactive prompt when running rm.
> If I start the service with an empty /storage/psqlReport, service success.
>
> What am I missing? Is there a better way to empty the directory before
> running my command ? The service will be timered, so can't empty
> manually.
>
> Thank you for help.
>
> --
>
> google.com/+arnaudgabourygabx
> ___
> 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] mknod forbidden in systemd-nspawn container

[Mantas Mikulėnas]

On Wed, Dec 23, 2015 at 3:10 PM, Emmanuel Coirier <ecoir...@olfeo.com>
wrote:

> Hello everyone,
>
> I have encountered a problem with a systemd-nspawn container and
> deboostrap running in this container.
>
> When I try to launch deboostrap inside the container, debootstrap stops
> because it tries to unpack a tar archive that creates devices like
> /dev/console. The error is "EPERM". Here is the full command list :
>

Hmm, isn't debootstrap supposed to run outside the container? Or are you
trying to nest two containers?

Anyway, nspawn containers by default limit devices via both POSIX
capabilities and cgroups; you would need --capability=cap_mknod to create
device nodes, and  to access them in case they're
not in the defautl whitelist.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DSC-statistics-collector fails to start

[Mantas Mikulėnas]

On Tue, Dec 22, 2015 at 12:34 PM, Federico Olivieri <lvrfr...@gmail.com>
wrote:

> Hi everybody,
>
> I was wondering if someone has experience with DSC DNS collector. Since
> last week, it fails to start in my server. Below the log output. No idea
> what it could be the problem (I had a look into the script indicated into
> the log message but for me seems ok) Anyone has any clue? :) Thanks!!!
>
> -- Unit dsc-statistics-collector.service has begun starting up.
> Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Starting DNS
> Statistics Collector (default): dsc-collectorcomplete failure
> Dec 22 10:29:22 raspberrypi dsc-statistics-collector[22066]: Pree.cc:70:
> assertion failed: 'i != rawEnd()'
> Dec 22 10:29:22 raspberrypi systemd[1]: dsc-statistics-collector.service:
> control process exited, code=exited status=134
>

The collector reports a crash in Pree.cc line 70, it's a bug in DSC itself
– not a systemd-related problem.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

On Tue, Dec 22, 2015 at 2:36 AM, Kai Krakow <hurikha...@gmail.com> wrote:

> Am Tue, 8 Dec 2015 01:36:01 +0200
> schrieb Mantas Mikulėnas <graw...@gmail.com>:
>
> > What uid does "oracle" have – is it within the system account range
> > (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> > which would mean systemd-logind would clean up various things like
> > IPC on logout... (see logind.conf)
>
> Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
> login.defs?
>
> Because I cannot find anything related to it in logind.conf which leads
> me to the assumption your reference was about RemoveIPC and friends
> only...
>

It's set at compile (configure) time – either obtained from the compile
host's login.defs or set with --with-system-uid-max=UID.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

On Tue, Dec 22, 2015 at 4:43 AM, Mike Gilbert <flop...@gentoo.org> wrote:

> On Mon, Dec 21, 2015 at 7:36 PM, Kai Krakow <hurikha...@gmail.com> wrote:
> > Am Tue, 8 Dec 2015 01:36:01 +0200
> > schrieb Mantas Mikulėnas <graw...@gmail.com>:
> >
> >> What uid does "oracle" have – is it within the system account range
> >> (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> >> which would mean systemd-logind would clean up various things like
> >> IPC on logout... (see logind.conf)
> >
> > Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
> > login.defs?
> >
> > Because I cannot find anything related to it in logind.conf which leads
> > me to the assumption your reference was about RemoveIPC and friends
> > only...
>
> I rather doubt the numeric value of the oracle UID has anything to do
> with the problem you are having.
>

It does, as Oracle uses SysV IPC and logind's behavior depends on UID.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "StandardOutput=console" don't work as expected

[Mantas Mikulėnas]

On Wed, Dec 30, 2015 at 2:40 AM, Reindl Harald <h.rei...@thelounge.net>
wrote:

> fine, on a real TTY (CTRL+ALT+F2) the echo appears (cluttered with echo
> and the PID instead just the output) but that don't help much in a
> SSH-Session..
>
>
> Am 30.12.2015 um 01:26 schrieb Reindl Harald:
>
>> why is there only logging instead "TEST" written to the terminal
>> starting a oneshot-service or in case it's a entry in /etc/crontab
>> triggering a cronmail becaus the output?
>>
>> that's not helpful when try to migrate cronjobs to systemd-units for
>> using ReadOnlyDirectory and other security otpions
>>
>
Pretty sure that's normal, +console here always meant /dev/console and not
"whatever stdout systemctl has".

Do you really have cronjobs which need to output stuff to ssh ptys?

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "StandardOutput=console" don't work as expected

[Mantas Mikulėnas]

On Wed, Dec 30, 2015 at 11:46 AM, Reindl Harald <h.rei...@thelounge.net>
wrote:

>
>
> Am 30.12.2015 um 10:37 schrieb Mantas Mikulėnas:
>
>> On Wed, Dec 30, 2015 at 2:40 AM, Reindl Harald <h.rei...@thelounge.net
>> <mailto:h.rei...@thelounge.net>> wrote:
>>
>> fine, on a real TTY (CTRL+ALT+F2) the echo appears (cluttered with
>> echo and the PID instead just the output) but that don't help much
>> in a SSH-Session..
>>
>>
>> Am 30.12.2015 um 01:26 schrieb Reindl Harald:
>>
>> why is there only logging instead "TEST" written to the terminal
>> starting a oneshot-service or in case it's a entry in /etc/crontab
>> triggering a cronmail becaus the output?
>>
>> that's not helpful when try to migrate cronjobs to systemd-units
>> for
>> using ReadOnlyDirectory and other security otpions
>>
>> Pretty sure that's normal, +console here always meant /dev/console and
>> not "whatever stdout systemctl has".
>>
>> Do you really have cronjobs which need to output stuff to ssh ptys?
>>
>
> i have hundrets cronjobs which are running silent and if there is
> something wrong then it's echo'ed which means with crond you get a mail
>
> and *no* it's no option to generate a mail at your own when you design
> software over years which runs aboslutely silent and so you know for
> trigger a alter mail you just need to echo the problem in whatever class
> method and you get also PHP warnings for free
>
> the whole point of using echo in cronjobs is that you don't need to know
> anything about the mail-environment, frankly even not need to have access
> to the MTA or sendmail binary from your script
>

Wait, so you're asking for StandardOutput=console to magically get piped to
/usr/sbin/sendmail instead of actual console?

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [help][227] Enabling a user service breaks a little my system!

[Mantas Mikulėnas]

On Thu, Nov 26, 2015 at 8:33 AM, Jorge Araya Navarro <elcor...@deshackra.com
> wrote:

> Hello!
>
> I'm suffering a issue with systemd's user services that I fixed only with
> a workaround, but today I
> want to fix this issue completely.
>
> I have created a user service which starts GNU Emacs, and another user
> service which starts GNU
> Screen[1], and enabled both.
>
> After rebooting my machine and login into my account, I get a pop up
> asking me to unlock my keyring,
> when it should be unlocked automatically after I login.
>
> Also, opening a shell and entering `systemctl --user` outputs the error:
>
> --8<---cut here---start->8---
> $ LC_ALL=C systemctl --user
> Failed to connect to bus: No such file or directory
> --8<---cut here---end--->8---
>

This sounds like a weird PAM problem... Do your regular login sessions show
up in `loginctl`? What $XDG_SESSION_ID do you see inside screen and outside?

Is the `user@$UID.service` system service running?


> [1]: This makes no sense, I know, I should put such service in
> `/etc/systemd/system/` and enable it
> as screen@myusername. I'll make this transition as soon as I solve my
> problem with systemd and
> environment variables.
>

On the contrary, it makes much more sense than abusing system services to
run per-user stuff.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] about systemd-logind

[Mantas Mikulėnas]

On Wed, Nov 18, 2015 at 9:07 AM, yan...@iscas.ac.cn <yan...@iscas.ac.cn>
wrote:

> Hi,when I  do like this "logindctl list session ",it tell me 0 sessions
> listed. The reasion I will  do this is that my nm-connection-editor can not
> add or modify  with administor ,and   if I do not have an active session
> with systemd-logind. So  does this related systemd-logind?
>

You need to have pam_systemd.so in your PAM configuration.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] about systemd-logind

[Mantas Mikulėnas]

On Wed, Nov 18, 2015 at 10:34 AM, yan...@iscas.ac.cn <yan...@iscas.ac.cn>
wrote:

> About PAM,I  am not clear.In my computer,there is pam_systemd.so in 
> /lib/x86_64-linux-gnu/security/
> .  And it does not matter.
>

Like I said, it needs to be listed in your PAM configuration – usually
/etc/pam.d/system-login or /etc/pam.d/common-session or similar. For
example:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/system-login?h=packages/pambase

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] about systemd-logind

[Mantas Mikulėnas]

On Wed, Nov 18, 2015 at 10:23 AM, yan...@iscas.ac.cn <yan...@iscas.ac.cn>
wrote:

> Do you mean /lib/x86_64-linux-gnu/security/pam_systemd.so? thank you!
>

Linux PAM configurations normally don't require the full path, but yes.

-- 
Mantas Mikulėnas <graw...@gmail.com>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] about administator Authentication agents

[Mantas Mikulėnas]

I remember Debian had an oddly restrictive policy for systemd bus access
(though it seems to be fixed now?).

On Mon, Nov 23, 2015, 14:24 Andrei Borzenkov  wrote:

> On Mon, Nov 23, 2015 at 11:00 AM, yan...@iscas.ac.cn 
> wrote:
> >
> > what is the relationship between systemd-logind and polkit.Because when
> I do
> > like this "systemd-analyze plot ",it tells   me  that  "failed to list
> > units:Access denied".About this ,I have no idea.
>
>
> It's not related to logind; this is answered directly by systemd and
> actually should not require any authentication (nor does systemd call
> polkit for ListUnits). I can only imagine that your D-Bus policy
> blocks it.
>
> Are you doing it as root?
> ___
> 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] question on special configuration case

[Mantas Mikulėnas]

This sounds like you could start by unsetting WatchdogSec= for those
daemons. Other than the watchdog, they shouldn't be using any CPU unless
explicitly contacted.

On Wed, Jun 8, 2016, 02:50 Hebenstreit, Michael <
michael.hebenstr...@intel.com> wrote:

> The base system is actually pretty large (currently 1200 packages) - I
> hate that myself. Still performance wise the packages are not the issue.
> The SSDs used can easily handle that, and library loads are only happening
> once at startup (where the difference van be measured, but if the runtime
> is 24h startup time of 1s are not an issue). Kernel is tweaked, but those
> changes are relatively small.
>
> The single problem biggest problem is OS noise. Aka every cycle that the
> CPU(s) are working on anything but the application. This is caused by a
> combination of "large number of nodes" and "tightly coupled job processes".
>
> Our current (RH6) based system runs with a minimal number of demons, none
> of them taking up any CPU time unless they are used. Systemd process are
> not so well behaved. After a few hours of running they are already at a few
> seconds. On a single system - or systems working independent like server
> farms - that is not an issue. On our systems each second lost is multiplied
> by the number of nodes in the jobs (let's say 200, but it could also be up
> to 1 or more on large installations) due to tight coupling. If 3 demons
> use 1s a day each (and this is realistic on Xeon Phi Knights Landing
> systems), that's slowing down the performance by almost 1% (3 * 200 / 86400
> = 0.7% to be exact). And - we do not gain anything from those demons after
> initial startup!
>
> My worst experience with such issues was on a cluster that lost 20%
> application performance due to a badly configured crond demon. Now I do not
> expect systemd to have such a negative impact, but even 1%, or even 0.5% of
> expected loss are too much in our case.
>
>
> -Original Message-
> From: Jóhann B. Guðmundsson [mailto:johan...@gmail.com]
> Sent: Wednesday, June 08, 2016 6:10 AM
> To: Hebenstreit, Michael; Lennart Poettering
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] question on special configuration case
>
> On 06/07/2016 10:17 PM, Hebenstreit, Michael wrote:
>
> > I understand this usage model cannot be compared to laptops or web
> > servers. But basically you are saying systemd is not usable for our
> > High Performance Computing usage case and I might better off by
> > replacing it with sysinitV. I was hoping for some simpler solution,
> > but if it's not possible then that's life. Will certainly make an
> > interesting topic at HPC conferences :P
>
> I personally would be interesting comparing your legacy sysv init setup to
> an systemd one since systemd is widely deployed on embedded devices with
> minimal build ( systemd, udevd and journald ) where systemd footprint and
> resource usage has been significantly reduced.
>
> Given that I have pretty much crawled in the entire mud bath that makes up
> the core/baseOS layer in Fedora ( which RHEL and it's clone derive from )
> when I was working on integrating systemd in the distribution I'm also
> interesting how you plan on making a minimal targeted base image which
> installs and uses just what you need from that ( dependency ) mess without
> having to rebuild those components first. ( I would think systemd
> "tweaking" came after you had solved that problem first along with
> rebuilding the kernel if your plan is to use just what you need ).
>
> JBG
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Mantas Mikulėnas]

In other words, mixing up OS file descriptors and Perl file handles?

D-Bus can only send and receive raw FDs; Net::DBus doesn't know what kind
of handle it's supposed to be, so you need to either create one manually,
or just work with the FD directly (I think the relevant function is
sysclose()?...)

On Wed, May 25, 2016, 22:57 Michael Hirmke  wrote:

> Hi again,
>
> [...]
> >>> - I am not able to close the file descriptor in the pre block of the
> >>>   signal handler. Whenever I try, I get an error, that the descriptor
> >>>   is closed.
>
> >>This suggests something else closed the fd for you?
>
> >Yes, but who or what might that be?
> >As I wrote above - at the moment I'm the only one using the system and I
> >have no idea, what component might fiddle with my file descriptors.
> >Do you have any hint, how I could find that out / debug it?
>
> >And there is the fact, that the lock is still in the list of inhibitors.
> >As far as I understand the docs, the entry should be gone when the fd is
> >closed.
>
> forget about that question - I have never asked it 8-((
>
> It was a really stupid error in my perl code - the file descriptor was
> never open. I got a file handle, but didn't realize that I have to open
> it myself. Now it works as expected.
>
> >>Lennart
>
>
> Bye.
> Michael.
> --
> Michael Hirmke
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl list failed daemons in computer-parsable format?

[Mantas Mikulėnas]

On Sat, Jun 11, 2016 at 5:16 PM, Patrick Schleizer <
patrick-mailingli...@whonix.org> wrote:

> Hi,
>
> does systemctl or some other tool have a method to create
> computer-parsable format for failed systemd daemons?
>

Use systemd's D-Bus API
<https://www.freedesktop.org/wiki/Software/systemd/dbus/>, that's how
systemctl gets its data in the first place.

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