Re: [systemd-devel] Start a global service
Lennart Poettering wrote in message <20170215172159.GA10587@gardel-login>: > Sorry, but this is unlikely to be added. I understand that this would be > handy, but this is semantically very questionable, as this would be > transition from privileged code into unprivileged code, and that's > something we can't really have. Ok, I understand, I'll just parse /run/user/*/systemd to get the active users (loginctl list-users is not very machine friendly) > systemd is not really a battery manager, use services like upower for > that, which do provide similar hooks. Fair enough. But I don't really see the point to have a daemon that will just listen to udev events for power change (udevd does other things which I do not need). I prefer my solution which calls directly systemd services. Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Start a global service
1) Feature request I would like a way [as root] to start a service on all active user sessions. Typically to start a user service that was installed globally. sudo systemctl --global start myservice.service will start myservice.service as a root user service, not on the other user sessions. 2) Feature request Something that could be usefull too is a special target (both for the user and system sessions) that is started automatically when there is ac loss, so that we run on battery, and conversely. We could even imagine systemd calling hooks like for systemd-sleep. It is of course not hard to do that on the system session with a udev rule, but I don't know how to start one automatically on the user sessions (hence my feature request above). I call my targets power-save.target and power-performance.target, but the name may not be generic enough, maybe something like ac-loss.target, ac-gain.target? 3) Usage Here is my current implementation of a system wide special power-save target. - In /etc/udev/rules.d, a rule: ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="[01]", RUN+="/usr/local/lib/powersave/bin/power-dispatcher %E{POWER_SUPPLY_ONLINE}" - power-dispatcher: if (($1)); then # 1 = plug systemctl --no-block start power-performance.target else # 0 = battery systemctl --no-block start power-save.target fi - power-performance.target: [Unit] Description=System power management: performance mode Conflicts=power-save.target - power-save.target: [Unit] Description=System power management: power-saving mode Conflicts=power-performance.target After=power-performance.target - power-save.service: [Unit] Description=Powersave mode (global service) PartOf=power-save.target [Service] Type=oneshot RemainAfterExit=true ExecStartPre=-/usr/bin/sleep 10 ExecStart=/usr/local/lib/powersave/bin/powersave true [Install] WantedBy=power-save.target - power-performance.service: [Unit] Description=Power performance mode (global service) PartOf=power-performance.target [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/local/lib/powersave/bin/powersave false [Install] WantedBy=power-performance.target Note: the sleep 10 in power-save.service is that in case of <10s ac loss, like happen often in trains or planes the powersave settings do not get applied. And it works very well! However for X display settings like 'xset +dpms', it would make more sense to run this as part of the user session, which has access to DISPLAY and XAUTHORITY. It is not too hard to find the active display as roots, but the DISPLAY without the XAUTHORITY is not enough (unless the user adds a 'xhost +si:localuser:$(id -un) somewhere'). So I could try to find which user is using which X display and find their .Xauthority but it gets cumbersome. Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] slow uefi firmware/boot
I apologize for the out of topic question, but since systemd-analyze incorporate the firmware boot time I wonder if you may have any trick to share in order to improve it. Here is my boot timing (using systemd-boot and a lz4 compressed initrd): $ systemd-analyzed Startup finished in 14.156s (firmware) + 1.098s (loader) + 7.473s (kernel) + 2.608s (initrd) + 1.766s (userspace) = 27.103s I have a few questions on how to improve things: - obviously for the firmware time there is not much to do except maybe try to turn off some uefi autodiscovery settings - the loader is perfect, I have configured it with 1s delay for the menu - I am surprised by the kernel time. What does it include? - the initrd time is fast but I am surprised too that it is slower than userspace [but I guess it is because of the mounting of / which also mounts /home as a subvolume]. The initrd is also handled by systemd, so the switch root is done by initrd-switch-root.service which calls /usr/bin/systemctl --no-block --force switch-root /sysroot I don't know how much information is transmitted during this switch, is there a 'systemd-analyze blame' I could do to see the time spent in the initrd (without using bootchart)? Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Secret machine-id for RFC 7217 stable addresses
Tom Gundersen wrote in message: > If I understand correctly, most of the point of RFC7217 is achieved > even if the secret key is known. The important point is to have a good > hashing function, and in that case knowing the secret key will not let > you discover any of the other parameters (which are the ones you > really want to hide). Well if you know the secret key and the hash, you can do an exhaustive search on the other parameters to recover them since they have low entropy. > Moreover, if the point is privacy, if an attacker has access (in some > way) to the machine-id, there is no point in him going after the > interface identifier as he can already identify the client. > Given those two facts, might it not be sufficient to use the > machine-id as the secret key after all? It all depends on your model of security. You could imagine an attack where an attacker known several machine-ids (for whatever reason, I can imagine for instance a client downloading a vm preseeded with a machine-id). Then when the client connects to the attacker, the attacker can try to hash all his known machine-ids and the other low entropy parameters into the hash function to get a match, in order to recover the machine-id and hence break privacy. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user service when x is started
From arnaud gaboury, Fri 07 Nov 2014 at 21:00:14 (+0100) : I maybe was not explicit enough. I have a bunch of user services started as soon as I log in. then I $ startx After this command, I would like systemctl --user start some services (window manager, etc). Yes, this is the same setup I use. The first bunch of services are grouped under the console.target. Now I am looking for a way to group GUI services in something like graphical.target (or whatever else name). As I said, you just need to ensure that when you startx, your session launch 'systemctl --user wm.target' automatically. I put this command in my '.xprofile' (because the *DM usually source this file), and my .xinitrc contains [ -r $HOME/.xprofile ] . $HOME/.xprofile so it works with startx too. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user service when x is started
My plan is to use after X is started a second target, let's call it wm.target, with all services relevant to the X session. For now, I have no idea how to define After= It can't be right after the console.target as X need to be started first. I don't understand, if you start X manually, why don't you launch systemctl --user wm.target from your .xprofile or an equivalent file? Maybe use systemctl import-environment DISPLAY before to get the correct $DISPLAY. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] segfault in timesyncd
Here are the logs: Nov 06 16:14:56 numenor systemd[1]: Started Network Time Synchronization. Nov 06 16:14:56 numenor systemd-timesyncd[4881]: Using NTP server 10.3.255.254:123 (10.3.255.254). Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply from 10.3.255.254:123 (10.3.255.254). Nov 06 16:15:06 numenor kernel: systemd-timesyn[4881]: segfault at 8 ip b77bea0a sp bfddf800 error 4 in systemd-timesyncd[b77b5000+1c000] Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service: main process exited, code=killed, status=11/SEGV Nov 06 16:15:06 numenor systemd[1]: Unit systemd-timesyncd.service entered failed state. Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service has no holdoff time, scheduling restart. I don't understand why I don't get a core dump, sending SIGABRT to a 'sleep' does produce one: Nov 06 16:09:39 numenor systemd-coredump[4321]: Process 4315 (sleep) of user 100 0 dumped core. And my systemd/system.conf does not have a DefaultLimitCORE, and indeed $ systemctl show systemd-timesyncd | grep LimitCORE LimitCORE=18446744073709551615 -- Damien ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Featur Request] Allow list of names in file.network
From Tom Gundersen, Thu 23 Oct 2014 at 20:14:45 (+0200) : Yes, this absolutely makes sense. Maybe even en*|usb*, like the udev logic. Happy to take a patch, but put on TODO for now. Great! I'll try to write a patch if I have the time! Thanks, Damien ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) : So, I really would prefer if this logic wasn't just a hook, but actually the primary action of logging in graphically via a display manager. Ok, and login off would just be something like 'systemctl stop gnome.target'? Note though that in the scheme I'd propose for GNOME we wouldn't support multiple parallel logins of the same user anymore. Instead, if you do this we'd add the seat you are logging into to your existing session. I sometime login from the same seat multiple times (to test my X settings). But I agree Xephyr would probably be better for this case. On multiseat setups you could hence merge multiple seats into a single meta-session with the workspace spanning all of the seats if you keep logging in with the same user. I could imagine having several virtual machines that connects via ssh -X to the main computer to launch graphical sessions (so that there is no need to install it on the vms); in this case there would be a need to start the same target but with different displays. And the solution I outlined on my preceding mail using instances target templates work very well (and it does since a long time, I was very impressed when I tried it and it worked out of the box); but having 'hooks' on logind would help a bit. But this is not really an important feature request for me, it was just an idea in passing. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shell expressions in EnvironmentFile
From Lennart Poettering, Wed 08 Oct 2014 at 20:48:55 (+0200) : SyslogIdentifier= should do it. It works, thanks! See systemd.exec(5) for details. When I was looking for something like that in the doc, I was confused by this passage: This option is only useful when StandardOutput= or StandardError= are set to syslog or kmsg., but it apparently actually works with StandardOutput=journal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Mantas Mikulėnas, Thu 23 Oct 2014 at 07:06:18 (+0300) : Wasn't this already fixed in polkit.git recently? Yes indeed: commit a68f5dfd7662767b7b9822090b70bc5bd145c50c sessionmonitor-systemd: prepare for D-Bus user bus model In the D-Bus user bus model, all sessions of a user share the same D-Bus instance, a polkit requesting process might live outside the login session which registered the user's polkit agent. In case a polkit requesting process is not part of the user's login session, we ask systemd-logind for the the user's display session instead. https://bugs.freedesktop.org/show_bug.cgi?id=78905 Wonderfull! The future is bright for user session :) With PA's socket activation, since mpd already has socket activation, the only thing I am still missing is ssh-agent socket activation! -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Zbigniew Jędrzejewski-Szmek wrote in message 20141019135812.gu29...@in.waw.pl: PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. But isn't using default.target more flexible than basic.target? When basic.target is activated I expect at least socket.target, timers.target and path.target to get activated too; whereas I could imagine an user wanting a completly empty user session [*], which could be done with an empty default.target [#]. [*] I don't use cron anymore, so I don't know if a cron session goes through systemd's pam module in my distribution's pam settings default, but I could imagine that if it were the case we would want a mostly empty user session in this case. [#] With DefaultDependencies=false Right now by default default.target is a symlink to basic.target. It seems natural that the user session starts default.target, like the system session does. Otherwise what would be the meaning of default.target? Something started by the DM when the user logs in rather than by pam? (Actually now that user sessions are getting more used, it would indeed be nice to standardize a name of a target to start when a graphical login is used!) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) : On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: But isn't using default.target more flexible than basic.target? When basic.target is activated I expect at least socket.target, timers.target and path.target to get activated too; whereas I could imagine an user wanting a completly empty user session [*], which could be done with an empty default.target [#]. basic.target includes sockets.target, busnames.target, timers.target and paths.target as well as sysinit.target. No, that's the system wide basic.target. The user basic.target only has sockets, timers and paths. But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. Yes, all user code really should go through PAM, so that security labels and resource limits can be set up properly. Yeah but do they need to go through pam_systemd.so also? Regarding graphical stuff: the way I figured this should work is that all desktop environments would define their own gnome.target, kde.target, xfce.target and then some graphical.target symlink would point to the preferred version. These targets would then bring up averything that's necessary for the specific session type. Ok, that looks nice. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) : Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the listening bits should be established, and everything else can be started later. Yes but maybe the user wants something even more minimal than basic.target. For instance if I run under a cron, maybe I don't want my timers to be launched. I was thinking of using a default.target with DefaultDependencies=false, so it does not even pull basic.target; not something that launch more things than basic.target. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Zbigniew Jędrzejewski-Szmek, Thu 23 Oct 2014 at 17:26:57 (+0200) : order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. I was more thinking of having a default.target that is even smaller than basic.target, but I forgot that we may want pam_systemd to start a session different from the synced session before login, so this also conflates two different use of default.target. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. Yes, this would be ideal. This way - pam_systemd starts default.target - the login returns when user-login.target is reached. [the question is what happen is default.target does not pull user-login.target; and I would argue that the login should return immediatly rather than wait for default.target] The important thing for me is that I may want default.target to be even smaller than basic.target; and I thought that syncing on basic.target would necessarily means launching it at each session, but maybe the implementation could be carefull about that. So in a scheme where - pam_systemd starts default.target - the login returns when basic.target is reached OR returns immediatly if basic.target is not pulled in I would be equally happy. The proposal by Zbigniew has my preference because it is more flexible, and does not conflates these three different things: - when to return for the login (user-login.target) - what services we want to launch by default (default.target) - when standard basic setup is considered done (basic.target) And unlike the system case where I always want default.target to requires basic.target, in the user case I may want default.target to be smaller than basic.target (for cron jobs I don't want my timers to launch); but still requires basic.target when I launch say xfce.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Interesting, does PA now support socket activation? Mine (pulseaudio 5.0) does not seem to support it. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. I have been using systemd user sessions for a long time, and it works really well, except for this policykit bug: https://bugs.freedesktop.org/show_bug.cgi?id=67728 For instance since I start dbus under the user session, the dbus activated services also run inside it: CGroup: /user.slice/user-1000.slice/user@1000.service ├─615 /usr/lib/systemd/systemd --user ├─616 (sd-pam) ├─dbus.service │ ├─ 702 /usr/bin/dbus-daemon --session --address=systemd: --nofork │ ├─ 835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor So udisks2 fails to mount my usb keys because it is not under an active session (since it is not launche from my active session) so it gets denied by policykit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Lennart Poettering wrote in message 20141020173828.GA4509@gardel-login: They should probably adopt socket activation anyway, otherwise they'd be quite annoying on multi-user systems if lingering is used. I am brainstorming here, but would it make sense to add hooks to logind when a session is started/closed (both system hooks and user hooks)? For instance when I log into X, my .xprofile contains systemctl --no-block --user start xsession@${DISPLAY}.target to start my user services. I need to make sure that everyway I have to log into X (with a *DM, with startx, with xinit) I somehow source .xprofile. Stopping the started services also involve some contorsion. When I quit X most of the services started by xsession@$DISPLAY fails because X is no longer available, and I don't want systemd to try to restart them in this case. So I need to stop these services whenever X exits. So inside xsession@.target, I launch xwatch@.service: [Unit] Description=Watch for X on display %I BindsTo=xsession@.target [Service] Environment=DISPLAY=%I SyslogIdentifier=xwatch@%I ExecStart=/bin/sh -c 'exec %h/mine/script/services/xwatch %I' Nice=19 [Install] WantedBy=xsession@.target with $ cat ~/script/services/xwatch #!/bin/sh xprop -spy -root XFree86_VT systemctl --user stop xsession@$1.target So whenever my X session stops, xwatch will stop xsession@$DISPLAY.target, and thus stop all services files that I configured to be PartOf xsession@.target. For instance xcompmgr@.service: [Unit] Description=xcompmgr on display %I PartOf=xsession@.target ConditionFileIsExecutable=/usr/bin/xcompmgr [Service] Environment=DISPLAY=%I ExecStart=/usr/bin/xcompmgr Restart=on-failure RestartSec=3 StandardOutput=null [Install] WantedBy=xsession@.target Also=xwatch@.service It works really well, I can even log onto different X sessions and have the corresponding services launched into the different $DISPLAY, but having some close hooks in logind would help getting rid of xwatch.service. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-journald watchdog timeout
On one boot I got a watchdog timeout on systemd-journald: Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M (m Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var is 2 Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not rea Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40 Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: authenticated Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 (capab Oct 21 20:08:25 feanor kernel: wlan0: associated Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link become Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to Persis Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and Directories Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization... Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System Boot/Shutdo Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System Boot/Shutdow Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization. Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization. Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization. Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket. Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0. Oct 21 20:08:25 feanor systemd-networkd[518]: lo : gained carrier Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd[1]: Started Network Service. Oct 21 20:08:25 feanor systemd[1]: Starting Network. Oct 21 20:08:25 feanor systemd[1]: Reached target Network. Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution... Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M (m Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout (li Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2. Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. Te Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout (l Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm timed o Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process exited Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered failed Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff time, Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service... Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Journal Service. As you can see at 20:08:20 things appears to look fine, but everything get stuck during 3 minutes until there is a watchdog timeout for the journal and it gets restarted. Then the boot finished without any further problem. The next time everything worked fine, so I am wondering what could have happened? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald watchdog timeout
From Lennart Poettering, Wed 22 Oct 2014 at 16:59:09 (+0200) : On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: That's difficult to say just from these logs. Yeah that was what I feared. Can you reliably reproduce this? If so, can you attach strace to journald before this happens and see what it is doing? Un(?)fortunately no. What I find interesting is that after the 3min pause suddenly the network driver allocates irq 55. This kinda makes me wonder if this might be a kernel/driver problem of some kind, where for some reason userspace (and hence journald) don't get scheduled? I am not sure this is related, on a non troublesome boot I also have similar lines: Oct 22 09:12:39 feanor systemd[1]: Started Network Service. Oct 22 09:12:39 feanor systemd[1]: Starting Network. Oct 22 09:12:39 feanor systemd[1]: Reached target Network. Oct 22 09:12:39 feanor systemd[1]: Starting Network Name Resolution... Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 22 09:12:39 feanor systemd-resolved[526]: Using system hostname 'feanor'. Oct 22 09:12:39 feanor systemd[1]: Started Network Name Resolution. Oct 22 09:12:39 feanor systemd[1]: Starting Multi-User System. Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 22 09:12:39 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read Oct 22 09:12:39 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40 What distro/version/arch is this? Up to date archlinux, kernel 3.16.4-1-ARCH x86_64, systemd 216-3. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) : On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote: But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. I have the impression that the current scheme already does everything what you need, no? I mean, if you list the template unit file in the preset file, and we enumerate such a template unit file, we end up enabling it's DefaultInstance=, which should be enough for you? Or am I missing something? For preset-all: - I may want to enable an instance different from the default instance. For example wpa_supplicant@.service does not have a default instance. (I could change the file but in this case I might as well write directly a non template service file) - I may want to enable different instances of the same template file. - disable * does not disable instanciated templates (except the ones with a default instance). But as you said, I do not see an easy way to do that the way preset-all works. Damien -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 09 Oct 2014 at 16:44:42 (+0200) : But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. This feels wrong. The preset files are actually globs, not full file names. They are not really suitable as a list of filenames, but only as something to match file names against... Yes, this is exactly what I was saying, sorry for the miscommunication... -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shell expressions in EnvironmentFile
Lennart Poettering wrote in message 20141008094838.GB26284@gardel-login: On Tue, 07.10.14 19:18, Simon Peeters (peeters.si...@gmail.com) wrote: ExecStart=/bin/sh -c . /something/that/sets/var; /some/file $var THis would certainly work, but I'd strongly advise to use exec for executing /some/file at the end, so that the shell process is replaced by the actual daemon process, instead of continuing running with the demon process as child. I am hijacking the thread because one minor inconvenience I have with sh -c 'exec foo' is that in journalctl the logging refers to 'sh': For instance: [Unit] Description=Git backup ConditionPathIsDirectory=%h/backups/gitbackup [Service] Type=simple ExecStart=/bin/sh -c 'exec %h/mine/script/gitbackup -v save' Nice=19 IOSchedulingClass=best-effort IOSchedulingPriority=7 gives me the log: Oct 08 21:35:43 mithrim sh[9680]: [master 54c23ae] Oct 08 21:35:43 mithrim sh[9680]: 2 files changed, 3 insertions(+), 3 deletions(-) Do you know of any way to get 'gitbackup' in the log rather than 'sh'? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 17:42:36 (+0200) : Hence so far the idea was to look for the presets only in the dirs where we look for static data, but not for configuration. We can certainly revisit this though. This makes sense for system services, but for user services it is a bit strange that a user cannot modify its own preset files. I'll be happy to provide a patch, but I must test the behavior of systemd more carefully because user preset files in /etc/systemd/user-preset/*.preset does not seem to work in systemd master [but maybe my testing was too hasty, I'll keep you updated]. Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 17:32:07 (+0200) : Would it be possible for the .preset file to just specify foo@.service and then the code that actually enables it just process the DefaultInstance rule as normal? That should already work, no? Yes it works: in 90-systemd.preset, the line enable getty@.service correctly enables getty@tty1.service -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 16:48:19 (+0200) : Well, but from somewhere systemctl preset-all needs to be able to discover the bar string... How is that supposed to work? preset-all just enumerates all unit files that are installed and enables/disables them according to the preset file. But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? I agree that since the enable/disable directive denotes glob, they are not well suited for instances services. Maybe add a new directive: instanciate foo@bar.service uninstanciate foo@bar.service (the uninstanciate is because disable does not disable instancied service for the same reason enable doe not enable them). I do not feel too strongly on this feature, afterwards it might as well be easier to call systemctl enable directly... Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Damien Robert, Fri 03 Oct 2014 at 19:18:31 (+0200) : From the preset file? I agree that since the enable/disable directive denotes glob, they are not well suited for instances services. Maybe add a new directive: instanciate foo@bar.service uninstanciate foo@bar.service (the uninstanciate is because disable does not disable instancied service for the same reason enable doe not enable them). Or activate/desactivate. But whatever the name, there is going to be some ugly interactions with enable/disable. (We would want desactivate to match globs too in order to be able to desactivate older instances, but then how do we check which has precedence between enable/disable/activate/desactivate). Maybe it is instead way easier to just directly call systemctl enable. Still, one feature missing is the ability to desactivate all services files (systemctl preset-all leaves the instances alone even with a disable *) in order to go back to a 'pristine' state from which one can call systemctl preset-all and then enable the instances. -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 16:07:03 (+0200) : How precisely would you envision this to work? I mean, so far systemctl preset foo@bar.service will precisely enable foo@bar.service That's exactly what I want; I have not tried systemctl preset foo@bar.service, but in 'systemctl preset-all' it does not work (it only enables services that exist, not instanciated service). , but you are expecting that systemctl preset foo@.service would somehow result in enablement of foo@bar.service or so? How would we even denote that in the rules files? No, I just want that enable foo@bar.service in a preset rule works with systemctl preset-all. Maybe I missed something and it already works? Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Featur Request] Allow list of names in file.network
This is a minor feature request for systemd-networkd: my files in /etc/systemd/network/ all share the same pattern: [Match] Name=en* [Network] DHCP=yes [Match] Name=eth* [Network] DHCP=yes [Match] Name=usb* [Network] DHCP=yes I would like to be able to only write one file, like [Match] Name=en*,eth*,usb* [Network] DHCP=yes or maybe to imitate extended globs like so [Match] Name={en,eth,usb}* [Network] DHCP=yes This would greatly facilitate adding common options like custom DNS and so on. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [feature request] allow instances in file.preset
I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. However it is a bit cumbersome that preset files do not parse instanced services files. I could play with DefaultInstance in foobar@.service.d/ droplets and add foobar@.service in the preset file (this works); but this only allow to configure one instance. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
Damien Robert wrote in message m01rcj$dhh$2...@ger.gmane.org: I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. Also according to the man file systemd.preset and my test, while user systemd units are looked in user folders: $XDG_CONFIG_HOME/systemd/user/* $HOME/.config/systemd/user/* ... preset files are only looked in system folders: /etc/systemd/user-preset/*.preset ... Is there a reason for that? Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
Zbigniew Jędrzejewski-Szmek wrote in message 20140925211702.gv29...@in.waw.pl: This seems to be a mis-design. I'm pretty sure we should allow users to set their own presets, so those directories underneath the home dir should be added. Ok great! I'll be happy to provide a patch but I have never hacked systemd before. Would something like that be ok? (not tested, just to see if I am in the right direction) Thanks, Damien Robert -- 8 - From 7755e4afc3dc24f50c97c28fd7c00fd576d882cc Mon Sep 17 00:00:00 2001 From: Damien Robert damien.olivier.robert+...@gmail.com Date: Fri, 26 Sep 2014 00:34:46 +0200 Subject: [PATCH 1/1] preset: read files in $XDG_CONFIG_HOME/systemd/user-preset/* This is the only way for a user to modify preset files as the other directory read /run/systemd/user-preset/*.preset /usr/lib/systemd/user-preset/*.preset are not user owned. --- man/systemd.preset.xml | 1 + src/shared/install.c | 24 ++-- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml index 55cb4de..9d414f4 100644 --- a/man/systemd.preset.xml +++ b/man/systemd.preset.xml @@ -49,6 +49,7 @@ parafilename/etc/systemd/system-preset/*.preset/filename/para parafilename/run/systemd/system-preset/*.preset/filename/para parafilename/usr/lib/systemd/system-preset/*.preset/filename/para + paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename parafilename/etc/systemd/user-preset/*.preset/filename/para parafilename/run/systemd/user-preset/*.preset/filename/para parafilename/usr/lib/systemd/user-preset/*.preset/filename/para diff --git a/src/shared/install.c b/src/shared/install.c index 61e572b..7981556 100644 --- a/src/shared/install.c +++ b/src/shared/install.c @@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state( int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const char *name) { _cleanup_strv_free_ char **files = NULL; +_cleanup_free_ char *user_preset = NULL; char **p; int r; @@ -1786,12 +1787,23 @@ int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const char #endif NULL); else if (scope == UNIT_FILE_GLOBAL) -r = conf_files_list(files, .preset, root_dir, -/etc/systemd/user-preset, -/usr/local/lib/systemd/user-preset, -/usr/lib/systemd/user-preset, -NULL); -else +if (user_config_home(user_preset) = 0) { +user_preset = strappend(user_preset, -preset); +if (!user_preset) +return -ENOMEM; +r = conf_files_list(files, .preset, root_dir, +user_preset, +/etc/systemd/user-preset, + /usr/local/lib/systemd/user-preset, +/usr/lib/systemd/user-preset, +NULL); +} +else +r = conf_files_list(files, .preset, root_dir, +/etc/systemd/user-preset, + /usr/local/lib/systemd/user-preset, +/usr/lib/systemd/user-preset, +NULL); return 1; if (r 0) -- Patched on top of v216-385-g79d80fc (git version 2.1.0) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
[Resending to the list since I was not posting through gmane but through gmail this time and my post was rejected because I was not subscribed to the list. Sorry for the spam] From Zbigniew Jędrzejewski-Szmek, Fri 26 Sep 2014 at 01:00:11 (+0200) : + paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename You seem to open an xml element, without closing it. Oups! A hasty copy and paste from systemd.unit +_cleanup_free_ char *user_preset = NULL; You can define this below, where it is used. According to CODING_STYLE it is better to declare all variables at the top of the function. -else +if (user_config_home(user_preset) = 0) { +user_preset = strappend(user_preset, -preset); +if (!user_preset) +return -ENOMEM; +r = conf_files_list(files, .preset, root_dir, +user_preset, +/etc/systemd/user-preset, + /usr/local/lib/systemd/user-preset, +/usr/lib/systemd/user-preset, +NULL); +} +else +r = conf_files_list(files, .preset, root_dir, +/etc/systemd/user-preset, + /usr/local/lib/systemd/user-preset, +/usr/lib/systemd/user-preset, +NULL); Please align all the if's at the same level, not nested. In fact they are part of the outer 'else if () {' and i was missing some brackets. Here is an updated patch, but I really need to test it inside a container first; I'll send you a real version asap. Thanks for your comments! -- 8 --- From: Damien Robert damien.olivier.robert+...@gmail.com Date: Fri, 26 Sep 2014 00:34:46 +0200 Subject: [PATCH 1/1] preset: read files in $XDG_CONFIG_HOME/systemd/user-preset/* This is the only way for a user to modify preset files as the other directory read /run/systemd/user-preset/*.preset /usr/lib/systemd/user-preset/*.preset are not user owned. Signed-off-by: Damien Robert damien.olivier.robert+...@gmail.com --- man/systemd.preset.xml | 1 + src/shared/install.c | 26 -- 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml index 55cb4de..3a45cbd 100644 --- a/man/systemd.preset.xml +++ b/man/systemd.preset.xml @@ -49,6 +49,7 @@ parafilename/etc/systemd/system-preset/*.preset/filename/para parafilename/run/systemd/system-preset/*.preset/filename/para parafilename/usr/lib/systemd/system-preset/*.preset/filename/para + paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename/literallayout/para parafilename/etc/systemd/user-preset/*.preset/filename/para parafilename/run/systemd/user-preset/*.preset/filename/para parafilename/usr/lib/systemd/user-preset/*.preset/filename/para diff --git a/src/shared/install.c b/src/shared/install.c index 61e572b..b666b96 100644 --- a/src/shared/install.c +++ b/src/shared/install.c @@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state( int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const char *name) { _cleanup_strv_free_ char **files = NULL; +_cleanup_free_ char *user_preset = NULL; char **p; int r; @@ -1785,12 +1786,25 @@ int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const char /lib/systemd/system-preset, #endif NULL); -else if (scope == UNIT_FILE_GLOBAL) -r = conf_files_list(files, .preset, root_dir, -/etc/systemd/user-preset, -/usr/local/lib/systemd/user-preset, -/usr/lib/systemd/user-preset, -NULL); +else if (scope == UNIT_FILE_GLOBAL) { +if (user_config_home(user_preset) = 0) { +user_preset = strappend(user_preset, -preset); +if (!user_preset) +return -ENOMEM; +r = conf_files_list(files, .preset, root_dir, +user_preset, +/etc/systemd/user-preset, + /usr/local/lib/systemd/user-preset, +/usr/lib/systemd/user
Re: [systemd-devel] cannot start swap unit on lvm
Alexey Shabalin wrote in message CAEdvWkQTe1rZ=+artom3hfr6rc8qgvbf2mgqfx44k+erjhp...@mail.gmail.com: [Swap] What=/dev/disk/by-uuid/a8ce6981-1afd-4af6-8783-784b3c7a7d64 systemctl start dev-disk-by\x2duuid-a8ce6981\x2d1afd\x2d4af6\x2d8783\x2d784b3c7a7d64.swap cannot activate swap, error by timeout. but swapon /dev/disk/by-uuid/a8ce6981-1afd-4af6-8783-784b3c7a7d64 fork fine. This looks a lot like the bug I had here https://bugs.archlinux.org/task/31306 I talk about a timeout for mounting /home, but mounting swap also timeouted. As you can see on the bug report, I have a similar setup to yours: swap on lvm, and referencing to it by the uuid. A possible explanation given by the arch maintainer was that the /dev/by-uuid links were not made, explaining why systemd could not find the filesystem. The swapon and mount works because they don't rely on these symlinks whereas systemd work. So if this is the case it would be more a udev problem than a systemd one. This happened with kernel 3.4.9, upgrading to 3.5.3 solved it (and strangely going back to 3.4.9 did not give back the problems, so I could not investigate further and the conditions for the bug to produce look to be quite unstable). Sorry, i know that swap on lvm bad idea, but ... I use lvm for my /, /boot, /home and swap partition and I really regret it. - Since grub2 went from 1.99 to 2.00, the lvm code changed, and the corresponding core.img does not longer fit in my 31.5kiB MBR gap. - I got the bug you mentioned - Currently with kernel 3.5.3 using ArchLinux the lvm detection fails in the initrd (the dm_mod module takes longer to load, so there is a race such that lvm vgchange --sysinit -a y sometime do not find the lvm partitions): https://bugs.archlinux.org/task/30966?string=lvm - it slows down the boot http://freedesktop.org/wiki/Software/systemd/Optimizations Next time I reinstall my computers I'll go with btrfs subvolumes instead! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl --user
in condition not absolute, ignoring: %h/.conkyrc while something like ExecStart=/bin/echo %h will work correctly and display my $HOME. This is really annoying with user service files, because I have to specify the home path manually, like in ExecStart=/home/username/script/services/xwatch %I rather than ExecStart=%h/script/services/xwatch %I and I don't always have the same $HOME (especially when I am not root...) 2) To work around the first problem, the services in ~/.config/systemd/user are symlinks pointing to a service file with the right hardcoded HOME. While systemctl start work fine with symlinks, systemctl enable does not: Failed to issue method call: No such file or directory (this is not too annoying since I can always make the symlinks myself) And the feature requests: 1) it would be nice to have a way to launch something when the service exit. (This is different from ExecStop is that it would be launched even if the service is not stopped by systemd). Maybe something like OnExitExec= (one could even imagine adding things like OnExitSuccessExec=, OnExitFailureExec=, OnExitAbortExec=) This would allow to write a pure systemd xwatch.service: [Unit] Description=Watch for X on display %I BindsTo=xsession@.target [Service] Environment=DISPLAY=%I ExecStart=/usr/bin/xprop -spy -root XFree86_VT OnExitExec=/usr/bin/systemctl --user stop xsession@%I.target [Install] WantedBy=xsession@.target 2) somewhat related: having a way to configure StartLimitAction= other than rebooting, which is not really usefull for user services. (this would allow to simulate OnExitExec= by putting it on StartLimitAction= and setting StartLimitBurst=1 and Restart=always, but it is probably not a good idea). -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Feature Request] systemctl --user status to output journal logs
Hi all, when using systemctl status foo.service, the last journald entries correspondingto this service are printed, which is a very nice feature of systemd. However, this is not the case when running a systemd --user, then systemctl --user foo.service will not print the corresponding journal logs, even if there are some. So here is to a feature request :) While I am at it, I have a question about how to distinguish in the user-mypid.journal what come from services started by the service systemd and what come from services started by systemd --user. A look at journalctl _AUDIT_LOGINUID=myid -o verbose show that the messages corresponding to services started by systemd --user could be identified by their _SYSTEMD_CGROUP of the form _SYSTEMD_CGROUP=/user/myname/8/systemd-30697/foo.service ^ so something like journalctl _SYSTEMD_CGROUP='the right regular expression' could print them, but journalctl does not seem to support regular expression yet. To tell the truth I was expecting to identify these messages by using _SYSTEMD_OWNER_UID=myid, but it seem that systemd --user does not set this property: I have some message with _SYSTEMD_OWNER_UID=myid in my logs but they do not correspond to messages generated by the services from systemd --user, so I don't really know what _SYSTEMD_OWNER_UID means :) Cheers! Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel