Re: [systemd-devel] udev device mapper rules for early boot?
'Twas brillig, and Nikolaus Rath at 10/12/12 19:03 did gyre and gimble:
Hello,
I have created a udev rule to set the owner of a specific block device:
SUBSYSTEM==block,
ENV{DM_UUID}==LVM-yYuoI8k05GWxZnz9BeEIwPUGGeojzF3dZZmXTYRqC051Tllj76OHdDlzYhKZUu7u,
OWNER=1000
If I disable and re-enable this logical volume with lvchange, it gets
created with the correct owner.
However, when I boot the computer, the device is always owned by
root:disk instead.
I checked my initrd, and the rule is present in lib/udev/rules.d as
99-udev-custom.rules.
Does anyone have a suggestion of how I could debug this further? Why is
my rule ignored when the volume comes up the first time?
Random guess: does that user exist in the context of the initrd?
I'd imagine any getent() calls would fail in the context of an initrd
unless you copy all the passwd+group etc. files too (which is arguably
not a good idea, but perhaps you can hack it in some small way)?
Like I say, just a guess.
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev device mapper rules for early boot?
'Twas brillig, and Nikolaus Rath at 11/12/12 16:31 did gyre and gimble:
On 12/11/2012 03:00 AM, Colin Guthrie wrote:
'Twas brillig, and Nikolaus Rath at 10/12/12 19:03 did gyre and gimble:
Hello,
I have created a udev rule to set the owner of a specific block device:
SUBSYSTEM==block,
ENV{DM_UUID}==LVM-yYuoI8k05GWxZnz9BeEIwPUGGeojzF3dZZmXTYRqC051Tllj76OHdDlzYhKZUu7u,
OWNER=1000
If I disable and re-enable this logical volume with lvchange, it gets
created with the correct owner.
However, when I boot the computer, the device is always owned by
root:disk instead.
I checked my initrd, and the rule is present in lib/udev/rules.d as
99-udev-custom.rules.
Does anyone have a suggestion of how I could debug this further? Why is
my rule ignored when the volume comes up the first time?
Random guess: does that user exist in the context of the initrd?
No. But that shouldn't be a problem. The other rules in the initrd also
refer to non-existing users (e.g. disk).
Are you sure that disk is the user here and not the group? Keep in
mind that dracut copies /etc/group to the initrd but only includes a cut
down /etc/passwd with just root and nobody defined...
I guess udev just waits until
passwd becomes available. Also, I tried specifying the UID instead of
the name, but that didn't help either.
I don't think udev waits until passwd becomes available. It's just a
hit and hope effort AFAIUI.
You'll need to teach your initrd about your user if you want it to be
owned by your user (i.e. somehow modify the dracut module
modules.d/99base/module-setup.sh or better add a new module 99myuser
or whatever, that is just a basic stub that just adds your user - that
way your change survives distro updates).
If you don't really care about the owner and the group is actually
enough for your needs then that should work fine (due to dracut copying
/etc/group from your system) - assuming of course that's where your
group is defined and it's not on some LDAP or YP/NIS system somewhere.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev device mapper rules for early boot?
'Twas brillig, and Nikolaus Rath at 11/12/12 17:52 did gyre and gimble:
On 12/11/2012 09:47 AM, Colin Guthrie wrote:
'Twas brillig, and Nikolaus Rath at 11/12/12 16:31 did gyre and gimble:
On 12/11/2012 03:00 AM, Colin Guthrie wrote:
'Twas brillig, and Nikolaus Rath at 10/12/12 19:03 did gyre and gimble:
Hello,
I have created a udev rule to set the owner of a specific block device:
SUBSYSTEM==block,
ENV{DM_UUID}==LVM-yYuoI8k05GWxZnz9BeEIwPUGGeojzF3dZZmXTYRqC051Tllj76OHdDlzYhKZUu7u,
OWNER=1000
If I disable and re-enable this logical volume with lvchange, it gets
created with the correct owner.
However, when I boot the computer, the device is always owned by
root:disk instead.
I checked my initrd, and the rule is present in lib/udev/rules.d as
99-udev-custom.rules.
Does anyone have a suggestion of how I could debug this further? Why is
my rule ignored when the volume comes up the first time?
Random guess: does that user exist in the context of the initrd?
No. But that shouldn't be a problem. The other rules in the initrd also
refer to non-existing users (e.g. disk).
Are you sure that disk is the user here and not the group? Keep in
mind that dracut copies /etc/group to the initrd but only includes a cut
down /etc/passwd with just root and nobody defined...
Yes, it's the group rather than the user. But no, that doesn't make a
difference. My initrd has neither /etc/group nor /etc/passwd. I'm using
Debian, so it's created with initramfs-tools rather than Dracut.
Hmm, OK, bang goes that theory then :)
I guess udev just waits until
passwd becomes available. Also, I tried specifying the UID instead of
the name, but that didn't help either.
I don't think udev waits until passwd becomes available. It's just a
hit and hope effort AFAIUI.
You'll need to teach your initrd about your user if you want it to be
owned by your user (i.e. somehow modify the dracut module
modules.d/99base/module-setup.sh or better add a new module 99myuser
or whatever, that is just a basic stub that just adds your user - that
way your change survives distro updates).
If that's the problem, why doesn't it help to specify the uid?
I dunno, I would have suggested that perhaps udev does a getent or
something before using UIDs or names, but if the whole disk thing works
fine (and it's definitely fine *in* the initrd and it's not just getting
reinitialised before you can look at it in the real system - the only
way to check this would be to put a shell/break in the initrd and
inspect before doing the pivot root. dracut has rd.break= arguments but
dunno what you'll have with initramfs-tools), then I'm out of ideas.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] daemon migration tutorial
'Twas brillig, and Dennis Semakin at 14/12/12 08:15 did gyre and gimble: Hello, I just want to ask you a question about daemon migration to systemd. I have daemon source code, I want to use it with systemd. Where can I find the information about this? Is there any centralized tutorial or document which contains the clear description of how to redesign daemon source code for using with systemd? Or this information is scattered on the following websites http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation2.html http://0pointer.de/blog/projects/journal-submit.html http://www.freedesktop.org/wiki/Software/systemd The last link contains links to all the Systemd For Developers tutorials including the ones you linked above it. Follow through there for an interesting read or so the plethora of man pages which also document everything (tho' perhaps not in quite as nice a form for a tutorial like need). IMO, it would be kinda nice to copy all of Lennart's articles to the Wiki to keep things in a central place (referencing the original blog story of course). Keeps things a bit more central. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev device mapper rules for early boot?
'Twas brillig, and Andrey Borzenkov at 14/12/12 02:58 did gyre and gimble: В Thu, 13 Dec 2012 15:35:11 -0800 Nikolaus Rath nikol...@rath.org пишет: On 12/13/2012 08:35 AM, Andrey Borzenkov wrote: Now, I could add the missing rule and program to the initrd, but I feel this is really opening a can of worms, since I don't really *need* to change the device ownership that early. Is there some way to have udev re-run this rule once it has been started properly by the real init? I guess turning the lv off and on again in some init script would do the trick, but that doesn't seem much cleaner either... This would be just another can of worms, really. Cannot you delay starting your volume until normal system boot phase? The only devices that are really required to be present in initrd are those for root (and may be for /usr if it is separate). Everything else can be started later. Yeah this is one of the reasons we switched to dracut from mkinitrd in Mageia (and in Mandriva too I believe). If you support / or /usr on LVM, then you really need to run udev in the initrd. Dracut makes that nice and easy. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecRestart
'Twas brillig, and Daniel P. Berrange at 20/12/12 10:44 did gyre and gimble: On Wed, Dec 19, 2012 at 11:46:13PM +0100, Lennart Poettering wrote: On Wed, 28.11.12 22:41, Brandon Black (blbl...@gmail.com) wrote: The daemon's fast restart code does all of the expensive startup operations in the new daemon first (e.g. parsing large data input), then signals the existing daemon to shut itself down, waits for it to release its critical resources (e.g. sockets, pidfile), and finally takes over those resources and finishes starting itself. Basically it's using the overlap to avoid long service downtimes during that initial parsing phase (and if that parsing fails, it leaves the old daemon running to boot). [snip] Or in other words: I am pretty sure that we should not alter the current restart logic, and should not introduce ExecRestart=. However, we really should think about either introducing ExecReexec= or somehow making ExecReload= useful for reexec-style reloading, too. But I haven't made my mind up on this, how this could look like. FWIW, as previously mentioned, I'd love to see an explicitly supported way to trigger a re-exec of a daemon. Currently I'm just relying on the ability to send a custom signal to libvirt's virtlockd daemon. The problem is that sysadmins would need to learn a different signal number for each project's daemon. So I think there's value to admins in having a standard way to trigger this via sysadmin. Personally I think this should also be separate from ExecReload which is merely used to refresh configuration files. Hmmm, this gives me a small idea. I've had a few users report similar things on different projects, e.g. one user complained that they used to use: service httpd closelogs but with systemd that no longer worked. Perhaps rather than trying to define a whole new language here we could instead define some generic way to send signals to a unit (obviously just to the main pid really) and some kind of nice way to cosmetically rename signals. e.g.: SignalMap=closelogs=HUP reexec=USR1 Then you could simply run: systemctl signal closelogs httpd.service Or something similar. Keeps things fairly defined still, but also gives a reasonable amount of flexibility. Of course running systemctl signal HUP httpd.service should also be supported and the SignalMap is really just a lightweight wrapper for cosmetic purposes. (this doesn't solve all the problems I've had reported of random verbs being used in initscripts. e.g. IIRC the postgres initscript had an initdb verb... this won't be solvable via this mechanism, but I don't think there is really a desire to allow ad-hoc verb registration in units with custom ExecVerb[initdb]=/usr/bin/... style syntax - I could be wrong tho'. FWIW Specifically in the postgres case I think it can be solved differently anyway with an ExecStartPre that checks to see if the db is init'ed and if not runs and init routine - that's how our mariadb stuff works these days I think and it seems robust enough) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to stop socket-actived inetd-like service?
'Twas brillig, and Petr Pisar at 20/12/12 13:01 did gyre and gimble: Hello, having cvs.socket: [Unit] Description=CVS Server Activation Socket [Socket] ListenStream=2401 Accept=true [Install] WantedBy=sockets.target and cvs@.service: [Unit] Description=CVS Server After=local-fs.target [Service] Environment=HOME=/var/cvs ExecStart=-/usr/bin/cvs -f --allow-root=/var/cvs pserver StandardInput=socket How can I stop all running instances? You probably want to put: PartOf=cvs.target Into your cvs@.service file (assuming you have a semi-recent systemd version). That way you can do systemctl stop cvs.target and it will kill all instances. You will also have to ship a simple .target file too. I start cvs.socket, I connect client to the TCP port, and now I want to stop all instances. Stopping cvs.socket disappears listening socket, but remaining cvs@*.service instances are still running. My naive attept to stop ther service is not recognized by systemctl: # systemctl stop cvs\@.service Failed to issue method call: Unit name cvs@.service is not valid. Failed to issue method call: Unit name cvs@.service is not valid. # systemctl stop cvs.service Failed to issue method call: Unit cvs.service not loaded. You can control individual units doing: systemctl stop cvs@foo.service (where @foo matches what systemctl list-units returns). HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: move legacy flag-files handling to legacy.conf
'Twas brillig, and Reindl Harald at 06/01/13 00:17 did gyre and gimble: Am 06.01.2013 01:13, schrieb Tom Gundersen: On Sun, Jan 6, 2013 at 12:59 AM, Reindl Harald h.rei...@thelounge.net wrote: on a running system the rootfs is not readonly It may be (i.e., systemd supports that setup if the rest of your software does), so it cannot be that a reboot always causes writes to the rootfs. please do not reply off-list and do not cut most of the previous post, i explained why touch /forcefsck is a godd idea and why deprecate anything which existed before systemd is a bad attitude You have a very odd way of expressing yourself here. As Lennart explained this is still *supported*. Putting it in a file called legacy.conf means very little in all practice, especially as this is a very simple tidyup routine, which is completely separate from the actual checking part itself (which would typically remove the file itself after the check anyway - this is just belt and braces). Even on systems with rw root, if I get some strange behaviour the first thing I'll do (if the kernel doesn't do it for me automatically) is mount -o remount,ro /. If I want to check the root fs, then the initrd will likely be the thing that actually does the check for me, not anything on the drive itself, so it's still isolated from the partition being checked. So I fully support the rationale that touch /forcefsck is a *bad* idea generally and any sysadmins that regularly use it should really try to use something with less impact going forward and try not to pass on bad habits. But there is no need to post sarcastic and unhelpful comments about something that actually *is* still supported (even if it is, for good reasons already mentioned, termed legacy). Of course the question of whether it is or is not supported in the future is more appropriate for the dracut mailing list (or $initrd_generator of your choosing), not here in systemd - because again, this is just a trivial tidy up routine to cleanup left over cruft and nothing to do with any actual execution of the check itself. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shutdown umount order
'Twas brillig, and Ilya Basin at 04/01/13 22:22 did gyre and gimble: Hi list. On shutdown I have Buffer I/O error on device dm-... because the truecrypt disk is unmounted later than the usb disk containing the truecrypt image. I think this happens, because 1) systemd can't figure out the correct mount dependencies 2) umount is called with the force flag - There are workarounds specially for truecrypt, but why not solve the problem entirely? 1) I think the mount dependencies can't be made 100% reliable. systemd should use the combination of them and /proc/mounts, but only as a HINT In my case /proc/mounts contains the right order. 2) Instead of force umount, systemd should first try to umount everything gracefully, and if at least one mount point was unmounted successfully, then retry. Only if all mounts are busy, systemd should force umount the first candidate and then repeat the graceful umount for others. I'm pretty sure the umounting/shutdown logic does exactly this already. It loops over the devices trying to unmount them and only when no changes on a complete run of the loop does it exit. http://cgit.freedesktop.org/systemd/systemd/tree/src/core/umount.c#n555 -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
Hi, Just thinking outload here as dealing with some packages where stuff in /etc was marked in the spec as %config and it really shouldn't be (I'm thinking dbus policy files and rootcerts mainly but there are do doubt countless other examples where this is true also). I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? I know this isn't true today, but with appropriate effort is that where we should be aiming? I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
'Twas brillig, and Lennart Poettering at 07/01/13 13:37 did gyre and gimble: On Mon, 07.01.13 11:48, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Just thinking outload here as dealing with some packages where stuff in /etc was marked in the spec as %config and it really shouldn't be (I'm thinking dbus policy files and rootcerts mainly but there are do doubt countless other examples where this is true also). I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? I know this isn't true today, but with appropriate effort is that where we should be aiming? I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). The stuff we design in systemd should work fine with an empty /etc. And I think it would be a nice goal to achieve this for the whole platform. That said, it's kinda unrealistic to achieve that anytime soon. On Android you can drop the configuration partition to do a firmware reset and we should really try to implement something similar with our /etc. There's a currently a lot of stuff in /etc though that really doesn't belong there. For example databases such as /etc/services or /etc/protocols really should live in /usr/share or so. It's fine allowing people to override these databases in /etc, but the upstream databse should not be considered primary configuration that should live in /etc. Cool, that's all basically matching my general feelings also. So now that most of the distros are nicely working on CoreOS stuff a bit more closely these days (with special kudos to the Arch folk I think!) we can probably all keep this in mind as we march forward. Getting the dbus stuff out of there would be a nice start me thinks :) Cheers! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-analyze-197 broken
'Twas brillig, and Kok, Auke-jan H at 14/01/13 23:55 did gyre and gimble: does systemd really need to introduce one 3rd party component after the next (libmicrohttpd as example) which will sooner or later terrible break due incompatible changes in this minefiled I don't think it's as bad as you portray it, but I have an intern software engineer that I will be making systemd-analyze (the non-plot parts - the plot parts should be replaced by bootchart IMO) rewrite in C, so hopefully we can put some of this behind us soon enough. I find the systemd-analyze plots pretty useful generally. It would be a shame to drop it in favour of bootchart if bootchart still requires a separate init to be run. i.e. I've got a problem on this boot right now, I'd like a quick graphical representation of it please! type use cases. I agree in principle with the other posts: i.e. less python deps if possible (it's just writing an svg? It's just XML why does it need a whole python backend??) and more useful information about timeouts and failed jobs etc. etc. So all I humbly ask here is that plotting from a normal, non-bootcharted boot is still kept around. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
'Twas brillig, and Frederic Crozat at 16/01/13 16:34 did gyre and gimble:
Hi,
on openSUSE, we found the need to sometime force --ignore-dependencies
when systemctl is called (usually from other services / initscripts /
tools started by initscripts and which can cause deadlock).
To handle this in a transparent manner, I'd like to introduce
SYSTEMCTL_OPTIONS environment variable, which, if set, would cause
systemctl to append its contents as if it was specified on command line.
Most common use case for this is using the --no-block and
--ignore-dependancies options. I found a need for this to prevent
deadlocks when certainly early packages (e.g. mandriva_everytime (if you
can remember back that far to your mdv days) which would do various h/w
fu (much of it outdated these days tho') and even start some services.
As this was done early in boot the starting of those services could
block in systemd - hence the need to use --no-block)
IIRC this is handled in the redhat initscripts (used also on Mageia -
dunno about suse...)
e.g. see this from /etc/init.d/functions (possibly a bit out of date and
IIRC slightly patched by me for Mageia too (the NO_BLOCK option)):
systemctl_redirect () {
local s
local prog=${1##*/}
local command=$2
local options=
case $command in
start)
s=`gprintf Starting %s (via systemctl): $prog`
;;
stop)
s=`gprintf Stopping %s (via systemctl): $prog`
;;
reload|try-reload)
s=`gprintf Reloading %s configuration (via systemctl):
$prog`
;;
restart|try-restart|condrestart)
s=`gprintf Restarting %s (via systemctl): $prog`
;;
esac
if [ -n $SYSTEMCTL_IGNORE_DEPENDENCIES ] ; then
options=$options --ignore-dependencies
fi
if [ -n $SYSTEMCTL_NO_BLOCK ] ; then
options=$options --no-block
fi
action $s /bin/systemctl $options $command $prog.service
}
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
'Twas brillig, and Frederic Crozat at 16/01/13 17:07 did gyre and gimble: I was planning to handle this environment variable in our tools but tools team would prefer to have it in systemctl. I guess I'll have to maintain this patch downstream in openSUSE :( It would seem to me that the tools is where it should be handled (as is done in the initscripts wrapper), but hey ho' - everyone prefers it done elsewhere. At least it's a relatively neat patch and hopefully it's need within Suse will disappear as the tools are refactored anyway? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - .gitignore Makefile.am src/bootchart src/core src/efi-boot-generator src/shared
'Twas brillig, and Kay Sievers at 21/01/13 11:03 did gyre and gimble: On Mon, Jan 21, 2013 at 7:29 AM, Andrey Borzenkov arvidj...@gmail.com wrote: commit f4ce2b3e5ce93b83f14f8785e205ebb5a9b8c1df Author: Lennart Poettering lenn...@poettering.net Date: Mon Jan 21 01:02:53 2013 +0100 efi: add efi boot generator that automatically mounts the ESP to /boot Has something changed? ESP has always been mounted on /boot/efi, and mounting it on /boot is plain wrong; ESP is shared resource for all OS installed, not private space to place files of this specific installation. The Linux kernel acts as an EFI boot loader, if copied to the ESP it can be directly executed by the EFI firmware. The initramfs and the kernel live in a vendor sub-directory in the ESP and are read directly by EFI code, and there is no need for grub2, any other additional filesystem driver, raid, network setup, or whatever additional code people think they would need to bring up all sorts of systems. The kernel itself with the initramfs can boot everything, has all the filesystem access which is ever needed, there is no need for anything else on EFI machines. Even the craziest setups can boot directly out of the firmware that way. It's the simplest and most efficient setup a system can have. And plain wrong is the sick game which is called grub2, not mounting the EFI partition at /boot. :) Forgive the noob question (as I have no EFI h/w to be bothered to learn this stuff!), but if What Andrey says is correct would this mean we cannot have two separate installs without sharing the same /boot? (or even a Windows install assuming it uses that space too?). Can you comment on those kind of set ups? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Someone working on gui for multiseat?
Hi, 'Twas brillig, and Stef Bon at 21/01/13 14:25 did gyre and gimble: I'm experimenting with the plugable ud-160-A as seat extender. I'm borrowing it from Hans de Goede. Now it works very good, only with new monitors using the newest EDID technique it blocks. Hans has already posted a patch. But with an older monitor it works great!! Now I would like contribute on the gui. I know it is very nice to have! I do not have recent experience creating guis, but for my on project I have to create a simple gui filebrowser as well. Is there already some working on that? Not sure what you mean by GUI here. Isn't it just GDM that pops up (or some other DE)? If so, I guess that's where you need to focus. Apologies if I've gotten the wrong end of the stick. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd down/upstream meeting at FOSDEM?
'Twas brillig, and Lennart Poettering at 22/01/13 22:11 did gyre and gimble: Heya, I just learned that a number of systemd downstream and upstream folks are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around. We were wondering whether it might be a good idea to meet up for some kind of systemd BOF at FOSDEM? My current thinking goes towards maybe lunch on saturday, but details about time and location are to be determined. Anybody else is coming who'd like to join us? Anybody from ArchLinux attending FOSDEM? SUSE? Or the other distributions? Saturday around lunchtime works for me. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vncserver@.service
'Twas brillig, and Antonio at 23/01/13 15:54 did gyre and gimble: Am 23.01.2013 16:29, schrieb Antonio: and why do you not use the User= and Group= options? Because they are not required by instructions. as also runuser, but one is native systemd the other not runuser is already written in the file. Well, whereever that file came from, it's wrong. systemd has built in tools to switch user and they should be used as things like runuser and su have a tendency to create their own sessions which is often not what you want. However I have just tried but permission error remains. ... User=antonio Group=antonio ... what about NOT reply offlist and provide informations like the output of systemctl status as also the current content of the unit-file? I'm replying even on systemd-devel list. I'm working with unit-file on Fedora ARM on Raspberry but I'm also replying you by Fedora on notebook. However: http://www.fpaste.org/NA2M/ That unit looks messy :s Try this: [Unit] Description=Remote desktop service (VNC) After=network.target [Service] Type=forking User=antonio Group=antonio ExecStartPre=-/usr/bin/vncserver -kill %i ExecStart=/usr/bin/vncserver %i -geometry 1024x600 -depth 24 -fp /usr/share/X11/fonts/misc ExecStop=/usr/bin/vncserver -kill %i [Install] WantedBy=multi-user.target Some notes: 1. syslog.target is old and not needed in recent systemd's 2. No need to shell out and ignore the return value of the Pre command. Use the - after the equals to ignore the return value of the command. It's output will be logged in the journal but that's fine IMO. 3. User=/Group= is a built in way to set the user and group. You should drop runuser completely as it's totally unneeded - systemd has this built in as documented in the manual. 4. I'm not sure of the %i usage above. You r spec mixed and matched a hard-coded :1 and some use of %i. If your service is vncserver@1.service, then you'll want to include the : in the commands, but if you are e.g. using vncserver@5900.service then I guess it's just an absolute number? (I forget the syntax of VNC server so forgive me if this is wrong!) 5. If you ultimately try to run vncserver with a 1 argument (meaning desktop :1 but actually translated directly as tcp port 1 then this may account for a permission error (regular users cannot listen on TCP ports 1024). Make sure you get your :1 vs. 1 correct. HTHs -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] InaccessibleDirectories and non-existing dirs
'Twas brillig, and Reindl Harald at 30/01/13 15:34 did gyre and gimble: systemd-197-1.fc18.2.x86_64 i try to make a generic list with folders which are never supposed to be access from httpd - but if you list here a non-existing directory httpd.service fails completly to start - as i can undersatnd this technically would it be not better to check if a dir exists and if not ignore the line silently? Well I guess a problem with that approach would be if the folder doesn't exist when the service starts but is then created after. An administrator would be forgiven for expecting the service not to be able to access this folder when reading the service, but AFAIUI, this would actually not be the case. I could be wrong of course and even if not it's maybe still acceptable behaviour. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: reuse the same /tmp and /var/tmp
[and the crowd goes wild!] Thanks for this work. I've also had a few bug reports about this one. 'Twas brillig, and Michal Sekletar at 02/02/13 09:10 did gyre and gimble: thank you very much for the review, it is very appreciated. I've sent out the patch to get a feedback on a general approach, since there are no objections to it, I will hack up the rest, inaccessible dirs, man page etc... As a small bit of bikeshedding/feature creep: would it be possible to name the directories with a little bit of context in them? e.g. it would be great if they could be called systemd-myunit-service-XX. There may be valid reasons for not doing this, but when debugging things and poking about as root user it might add a little bit of clarity when several such folders exist (of course slight obfuscation here may be deliberate) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SSL for gatewayd
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 16/01/13 20:55 did gyre and gimble: On Wed, Jan 16, 2013 at 09:33:22PM +0100, Holger Winkelmann wrote: Can't speak from person experience, but my team has worked with the libevent and libev libraries which contain http libraries as well. IIUC, libev uses libevent code for HTTP through a compatibility layer. libevent has only very basic functionality. E.g. I couldn't see a mention of POST requests anywhere. libmicrohttpd at least abstracts this to the point where I only have to provide a callback to consume buffers with data. Also, libevent/libev are about abstracting event loops. Since journald is linux only, this extra abstraction layer is not very useful. Whist having next to zero experience of libevent, I happened to attend a talk at FOSDEM which mentioned patches to support SSL which is used by Facebook to power their HipHop PHP system (i.e. it bypasses apache and just accepts connections directly). See here for the patch details: https://github.com/facebook/hiphop-php and the patch in question: https://github.com/facebook/hiphop-php/blob/master/src/third_party/libevent-1.4.14.fb-changes.diff Looking over it now a little, I'm not actually sure it's related to SSL after all, but rather a bit more about exposing the fd (thus perhaps helping to integrate it a bit easier) and also some async stuff which is also presumably a good thing. Anyway, just thought I'd share in case it's useful. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Booting with USB flash disk installed results in wrong disk numbering
'Twas brillig, and Baurzhan Muftakhidinov at 05/02/13 13:30 did gyre and gimble: Alright, I've tried on netbook and on relatively powerful laptop to boot 10 times latest ArchLinux's archboot image from the USB drive. On laptop, hard disk was /dev/sda 10 times out of 10 tries, On netbook, only 3 times hard disk was /dev/sda and 7 times USB drive became /dev/sda. What concerns me here is that there is no consistency on less powerful machine. So I should just believe in the RANDOM choice on every boot on my netbook? On Debian with sysvinit it works just fine. When I change sysvinit to systemd (kernel and udev are the same), I see the situation I am talking here. This is what I asked for, maybe there is some kind of timeout for detecting disks. As others have already commented, you simply should not use /dev/sd* at all in any definition either on the kernel command line or in your fstab. Distros switched many years ago to using UUIDs for fstab and kernel command line entries - long before systemd existed. Forget those /dev/sd* names, they are meaningless. Use the UUID or use the LABEL. Anything else is just going to break in confusing ways. Solutions for the problem already exist - better just to use them. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] units: Make getty@.service install rule generic.
The getty@.service used to specifically enable a getty@tty1.service under getty.target when enabled. Modern versions of systemd allow commands such as: systemctl enable getty@tty2.service which automatically create the correct symlink if the Install rule permits it. This changes the default getty@.service to follow this now standard convension. Note: Packagers may need to change their initial install rules due to this change (e.g. in rpm %post etc) --- units/getty@.service.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/getty@.service.m4 b/units/getty@.service.m4 index 083eb97..bd89a47 100644 --- a/units/getty@.service.m4 +++ b/units/getty@.service.m4 @@ -48,4 +48,4 @@ Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETA KillSignal=SIGHUP [Install] -Alias=getty.target.wants/getty@tty1.service +WantedBy=getty.target -- 1.8.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck change fsck arguments to -a - -y
'Twas brillig, and Kok, Auke-jan H at 08/02/13 08:04 did gyre and gimble: On Thu, Feb 7, 2013 at 3:38 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 07.02.13 16:57, Bryan Duff (bd...@ecessa.com) wrote: Would it be possible to add this as some kind of option to systemd-fsck? In my case there was a situation where ext3 would not mount because of a timestamp issue that would not be fixed with -a. Every sane distro patches the timestamp check nonsense out of e2fsck. Assuming the RTC was always correct is just so misguided, it hurts... ACK, sadly, I've applied this patch too several times... By patches here I think all we did was ship a /etc/e2fsck.conf with: [options] # This will prevent e2fsck from stopping boot just because the clock is wrong broken_system_clock = 1 in it. I don't think there is much else needed (please correct me if I'm wrong!). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck change fsck arguments to -a - -y
'Twas brillig, and Kay Sievers at 08/02/13 11:21 did gyre and gimble: On Fri, Feb 8, 2013 at 12:05 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 08/02/13 08:04 did gyre and gimble: On Thu, Feb 7, 2013 at 3:38 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 07.02.13 16:57, Bryan Duff (bd...@ecessa.com) wrote: Would it be possible to add this as some kind of option to systemd-fsck? In my case there was a situation where ext3 would not mount because of a timestamp issue that would not be fixed with -a. Every sane distro patches the timestamp check nonsense out of e2fsck. Assuming the RTC was always correct is just so misguided, it hurts... ACK, sadly, I've applied this patch too several times... By patches here I think all we did was ship a /etc/e2fsck.conf with: [options] # This will prevent e2fsck from stopping boot just because the clock is wrong broken_system_clock = 1 in it. I don't think there is much else needed (please correct me if I'm wrong!). Right. Don't forget to put it into the initramfs, if needed. Yup, dracut copies if it's present already, but make sure to modify any other initramfs generator if it doesn't do that. Well, there will be btrfs ... :) One day... :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Allow the 'udevadm settle' timeout to be set via the kernel cmdline
On some really old hardware, the default timeout of 120 (which may even
be reduced further on the command line) is insufficient.
While such cases are specialist and (nowadays) relatively rare, it is
still nice to be able to provide a method to increase the timeout
when needed.
Bug Link: https://bugs.mageia.org/show_bug.cgi?id=3315
---
I posted this one a while back before udev merge IIRC and was asked to
make it use the newer APIs etc. which I've done. Can't remember if I
reposted it back to the list or not. Would be nice if it was upstream
just to save me carrying a fairly generic patch downstream.
It's quite a small patch, but there is no doc on this. Is there a file
into which I should put a small chunk of doc on this option?
src/udev/udevadm-settle.c | 32
1 file changed, 32 insertions(+)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index c4fc4ee..1871071 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -53,6 +53,7 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[])
int quiet = 0;
const char *exists = NULL;
unsigned int timeout = 120;
+char *line;
struct pollfd pfd[1] = { {.fd = -1}, };
struct udev_queue *udev_queue = NULL;
int rc = EXIT_FAILURE;
@@ -99,6 +100,37 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[])
}
}
+/*
+ * read the kernel commandline, in case we need to tweak timeout
+ * udev.settle-timeout=timeout settle timeout
+ *
+ */
+if (read_one_line_file(/proc/cmdline, line) = 0) {
+char *w, *state;
+size_t l;
+
+FOREACH_WORD_QUOTED(w, l, line, state) {
+char *s, *opt;
+
+s = strndup(w, l);
+if (!s)
+break;
+
+/* accept the same options for the initrd, prefixed
with rd. */
+if (in_initrd() startswith(s, rd.))
+opt = s + 3;
+else
+opt = s;
+
+if (startswith(opt, udev.settle-timeout=)
safe_atou(opt + 20, timeout) = 0)
+log_debug(timeout=%i (via kernel cmdline)\n,
timeout);
+
+free(s);
+}
+
+free(line);
+}
+
udev_queue = udev_queue_new(udev);
if (udev_queue == NULL)
exit(2);
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Allow the 'udevadm settle' timeout to be set via the kernel cmdline
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 08/02/13 12:14 did gyre and gimble: On Fri, Feb 08, 2013 at 11:48:36AM +, Colin Guthrie wrote: On some really old hardware, the default timeout of 120 (which may even be reduced further on the command line) is insufficient. While such cases are specialist and (nowadays) relatively rare, it is still nice to be able to provide a method to increase the timeout when needed. Bug Link: https://bugs.mageia.org/show_bug.cgi?id=3315 --- I posted this one a while back before udev merge IIRC and was asked to make it use the newer APIs etc. which I've done. Can't remember if I reposted it back to the list or not. Would be nice if it was upstream just to save me carrying a fairly generic patch downstream. It's quite a small patch, but there is no doc on this. Is there a file into which I should put a small chunk of doc on this option? kernel-command-line(7), udevadm(8) You can just always have a look at http://www.freedesktop.org/software/systemd/man/systemd.directives.html and look at similar options. Ahh thanks. I never actually realised that systemd.directives contained more than just the stuff that worked in unit files... silly me. Will add some stuff to those files and resubmit in due course (unless Kay says he doesn't want to commit it upstream in which case I won't bother! :p) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network/openvswitch dependency loop/deadlock
'Twas brillig, and Ian Pilcher at 08/02/13 21:00 did gyre and gimble:
On 02/07/2013 06:13 AM, Colin Guthrie wrote:
Also re the initscripts tweaks and the if statement proposed in the bug,
there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that
will make service openvswitch start pass the --ignore-dependencies
argument if it redirects to systemctl. That's likely cleaner than the if
[ -x /usr/bin/systemctl ] check.
FYI, I just tried this on Fedora 18, and it didn't work. It looks like
the version of systemctl in F18 may not recognize that variable:
$ strings /usr/bin/systemctl | grep SYSTEMCTL_IGNORE_DEPENDENCIES
$
Oh well.
This isn't something built into systemctl itself, but rather in the
/usr/bin/service wrapper and in initscripts functions generally:
e.g. in the initscripts git: git://git.fedorahosted.org/initscripts.git
[colin@jimmy initscripts (master)]$ git grep SYSTEMCTL_IGNORE_DEPENDENCIES
initscripts.spec:- /sbin/service: honor SYSTEMCTL_IGNORE_DEPENDENCIES
(lenn...@poettering.net)
rc.d/init.d/functions:if [ -n $SYSTEMCTL_IGNORE_DEPENDENCIES ]
; then
service: export SYSTEMCTL_IGNORE_DEPENDENCIES=1
service: env -i PATH=$PATH TERM=$TERM
SYSTEMCTL_IGNORE_DEPENDENCIES=${SYSTEMCTL_IGNORE_DEPENDENCIES}
SYSTEMCTL_SKIP_REDIRECT=${SYSTEMCTL_SKIP_REDIRECT} ${SERVICEDIR}/${SERVICE
service: env -i PATH=$PATH TERM=$TERM
SYSTEMCTL_IGNORE_DEPENDENCIES=${SYSTEMCTL_IGNORE_DEPENDENCIES}
SYSTEMCTL_SKIP_REDIRECT=${SYSTEMCTL_SKIP_REDIRECT} ${ACTIONDIR}/${SERVICE}
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] Remove installation of symlinks in /etc
'Twas brillig, and Umut Tezduyar at 12/02/13 12:00 did gyre and gimble: If I am not mistaken, moving getty@tty1.service and remote-fs.target to $systemunitdir will cause them to be shown as disabled on systemctl status .unit even though they are enabled. These unit files have [Install] sections and when there is [Install] section on them, systemd will look for a symbolic link in /etc to determine if the unit is enabled/disabled. If the mentioned unit files are moving to $systemunitdir, then their [Install] section needs to be removed as well so systemd can treat them as static unit files. Should we not just drop them completely? AFAIK, most distros don't ship those files but instead recreate them in %post install scripts. Certainly, I've created distro-wide rpm-lint rules that prevents any package from shipping any files inside /etc/systemd/system/ (links or real units), and ditto for udev rules etc. I'm very much trying to promote a tidy /etc these days :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: Make getty@.service install rule generic.
'Twas brillig, and Lennart Poettering at 13/02/13 03:13 did gyre and gimble: On Wed, 06.02.13 09:47, Colin Guthrie (co...@mageia.org) wrote: The getty@.service used to specifically enable a getty@tty1.service under getty.target when enabled. Modern versions of systemd allow commands such as: systemctl enable getty@tty2.service which automatically create the correct symlink if the Install rule permits it. This changes the default getty@.service to follow this now standard convension. Note: Packagers may need to change their initial install rules due to this change (e.g. in rpm %post etc) Hmm, but what happens then if people do run systemctl enable getty@.service? We really need to get the story right on this, I guess, so that something useful happens in both cases? The same could be said of any templated unit with a WantedBy= section I guess. One idea off the top of my head is to have a NoInstanceAlias= directive, but adding a new verb here seems fugly. Perhaps we could abuse the - syntax? e.g.: Alias=-getty.target.wants/getty@tty1.service WantedBy=getty.target With - in an Alias meaning The Alias to be used when no instance name is given in the enable/disable commands. If an instance name is supplied the Alias is ignored and any WantedBy directives are processed. To be doubly robust, it could be a parse error in any unit that is not a template. That might also be considered a little ugly too, but saves on a new directive and still mostly fits the silent degradation meaning of -. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: Make getty@.service install rule generic.
'Twas brillig, and Thomas Bächler at 13/02/13 10:01 did gyre and gimble: Am 13.02.2013 10:29, schrieb Colin Guthrie: Hmm, but what happens then if people do run systemctl enable getty@.service? In my eyes, doing this always seemed wrong, I wouldn't mind if it returned an error. Yeah, I'm personally OK with that too. We really need to get the story right on this, I guess, so that something useful happens in both cases? The same could be said of any templated unit with a WantedBy= section I guess. One idea off the top of my head is to have a NoInstanceAlias= directive, but adding a new verb here seems fugly. I actually like the idea of adding a DefaultInstace= option to the install section. Instead of fiddling with aliases manually, it could look like this: [Install] WantedBy=getty.target DefaultInstance=tty1 Actually yeah, that looks kinda neat. I think that syntax would justify a new verb. Instead of going to [Install], this could even go to [Unit] and affect start/stop, not just enable. Interesting idea. Might be somewhat confusing overall however. I guess there is an argument for being explicit for start/stops, even if enable/disable support the instanceless syntax. Perhaps we could abuse the - syntax? e.g.: Alias=-getty.target.wants/getty@tty1.service WantedBy=getty.target Manually writing an alias here seems redundant - you shouldn't have to write an alias when what you do is pretty much standard. If DefaultInstance was implemented in the [Unit] section, I guess Alias should gain %i/%I replacement support just to be complete. With it bailing with an error when DefaultInstance was not supplied and no instance provided on the command line. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network/openvswitch dependency loop/deadlock
'Twas brillig, and Lennart Poettering at 13/02/13 03:06 did gyre and gimble: On Tue, 12.02.13 14:07, Thomas Graf (tg...@redhat.com) wrote: On 02/07/2013 04:55 PM, Ian Pilcher wrote: On 02/07/2013 06:13 AM, Colin Guthrie wrote: Also re the initscripts tweaks and the if statement proposed in the bug, there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that will make service openvswitch start pass the --ignore-dependencies argument if it redirects to systemctl. That's likely cleaner than the if [ -x /usr/bin/systemctl ] check. Obviously as this is arguably not the right fix anyway, it's perhaps a moot point. Cool. So given that it is in fact After=... network.target (in openvswitch.service) that is causing the problem, do you see a better solution than using SYSTEMCTL_IGNORE_DEPENDENCIES? Is there any chance that this would work? After=syslog.target Requires=network.target (While not breaking the use case in comment #34 of the bug.) I'm very unclear on what Requires=network.target would actually mean. The case of Open vSwitch is a bit special because there is a chicken egg problem. OVS bridges and ports are configured using the ovs-vsctl utility. It requires the OVS daemons to be running. So naturally we want to start the openvswitch unit (if it is not running yet) before we ifup any OVS type interfaces. We also want the openvswitch unit to be started after network on boot because an OVS bridge may be using a controller on the network that depends on network connectivity. So what we did is introduce a new ifcfg key that can be used to define the interface dependencies of a bridge. Let's say ovsbr0 is configured to use a controller that is behind interface em1. So before bringing up ovsbr0 we want to bring up em1 and after that we want to start the openvswitch unit and then configure the bridge. So it seems what we need is a way to tell systemd to disregard the network dependency if we are starting the openvswitch unit from within ifup. Something like --ignore-dependency=network.target because we still want it to depend on syslog.target obviously. I guess we could also be providing a separate units files: openvswitch-no-network.service openvswitch.service What is cleaner from a systemd perspective? Well, there still is a dep loop, that is unfixed, right? I mean, you want your service to run as part of bringing up some networks, but also after the network is up. So what do you want now? Start it after or at the same time, that's contradicting. a) if you want to start it only after then, you should drop those callouts from ifup. b) if you want to start it as part of the network config, then you should drop any reference to network.target. To me it appears that you aren't entirely clear which way you want it, and try to use --ignore-dependencies as a work-around for that... But I really think the first step needs to be: what it's gonna be? Is what is really needed here some kind of netdev-generator which parses the individual ifcfg-* files and writes out netdev@eth0.service instances (or maybe not a single netdev@.service but several for the different kinds of interfaces?) That way the deps can be properly parsed and ordered in the units. Actually due to the interplay of deps it might not be possible to use templated units here, but just generate specific, individual units (just like mount units). Either way, is a generator the way to go here longer term, or is there some other plan afoot to modernise the static network configs? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] troubleshooting different behaviour of systemd between f16 and f18
'Twas brillig, and Thierry Parmentelat at 13/02/13 14:03 did gyre and gimble: Hi Kay; thanks for taking the time to write this down I understand what you guys are saying; and at first sight I am on the safe side here though (as the name suggests, pl_sysinit will only mount filesystems and init network interfaces and the like) However your answers do not shed any light on the reason why pl_sysinit does not seem to be triggered *at all* (unless again this is only an artifact of the output policy) Forgive me if I've missed this already, but have you checked/supplied the output from: systemctl status pl_sysinit.service ?? If the ExecStartPre somehow returns non-zero, then ExecStart will not be run. The status output will tell you the return status of the ExecStartPre command. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] Remove installation of symlinks in /etc
'Twas brillig, and Lennart Poettering at 13/02/13 00:21 did gyre and gimble: On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote: Contrary to it's own packaging guidelines, these symlinks are created in /etc/. While technically not a problem, this makes it harder for folks installing from git that want to override these settings (either masking or otherwise). Moving the links to $(systemunitdir) resolves. I am not sure we really should do this. Both of these units should be allowed to be disabled, and always telling people to mask them sounds a bit too much... Dunno, I am a bit split about this. I see where you are coming from, but just making them static sounds like too simple... (Also, if we make them static we'd drop the [Install] section, as that would be pointless then...) So, I am really unsure... Dunno... Opinions? As a compromise, how about dropping them from make install, but then adding a new make install-foo rule that does install plus a few extra bits and bobs so that those building from git can get their working system easily without too much subsequent manual fiddling. Yes, this requires those building and running from git know about install-foo but I would hope such people are fairly competent and know at least roughly what they are doing before taking such action anyway Obviously a better name than foo is needed. install-bootstrap?. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do you set the machine's domain name with systemd?
'Twas brillig, and Reindl Harald at 13/02/13 20:01 did gyre and gimble: besides that Lennart's PC is technical absoluetly not needed But I want nice names showing up on my networked PCs at home when they show up in my media centre. A pretty host name is IMO a needed concept. Whether that fits in with your world view or not is obviously a different story... but then, hey, aren't hostnames themselves technically absolutely not needed. An IP address should be sufficient. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] NFS mount unit
'Twas brillig, and Patrick Donnelly at 15/02/13 20:44 did gyre and gimble: I am trying to setup a mount unit file for an NFS mount. I'm using (with IP address hidden): # cat host\@.mount [Unit] Description=%i mount DefaultDependencies=no Requires=local-fs.target network.target rpc-statd.service Conflicts=umount.target [Mount] What=host:/%i Where=/%i Type=nfs Options=user,async,atime,exec,rw,wsize=32768,rsize=32768 DirectoryMode=0755 TimeoutSec=20 [Install] WantedBy=multi-user.target When trying to enable the mount unit, I get this error: # systemctl enable ./host\@mnt.mount Failed to issue method call: Invalid argument Don't use the paths ./ as a prefix. Just ensure your unit is located in /etc/systemd/system and do: systemctl enable host@mnt.mount No need to escape anything. This error message is unfortunately (and frustratingly) vague. What am I doing wrong? [Before someone asks why not use /etc/fstab, I'm planning to add an openvpn dependency when I get these issues sorted out.] Can't you just make openvpn.service also part of network.target? Thus holding up network.target until after it's started and thus delaying the mount until that point (even when the mount is generated from fstab). Alternatively, would it make sense to teach the fstab generator some kind of x-system-* option (or comment= syntax) to allow -after or -requires deps to be specified. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] High CPU usage of journald
'Twas brillig, and Holger Hans Peter Freyther at 18/02/13 18:52 did gyre and gimble: On Mon, Feb 18, 2013 at 08:47:44AM -0800, David Strauss wrote: Dear David, all, It's possible that a lot of it could also allocate on the stack or use stack-style management of a pool in heap. This is pretty performance-critical code, and we're seeing similar CPU overhead. I think upstream doesn't care about the CPU overhead of the journald. I don't really think that's true. It certainly hasn't been optimized heavily yet, and more concentration is definitely going into features at present, but that's not to say that performance isn't a goal in the completeness of time. Also there will be lots of people for whom this is more of a priority right now and thus they will be the ones perhaps contributing the patches to help edge things in that direction :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest!
'Twas brillig, and David Strauss at 19/02/13 07:08 did gyre and gimble: I'd like to participate online. Will people be joining a Google+ Hangout or the #systemd IRC channel? I'm personally interested in TLS support for the gateway. I have quite a bit of x.509 experience to add for development and documentation. I'd also like to join online in some capacity, tho' have a very busy week this week at $dayjob :s Also I think my G+ Hangouts are a bit broken right now due to some cairo update :s But I'll try and be around. For me, one of the biggest issues is still one around that of x-distro unit sharing for units that are not in upstreams (either because upstream is not accepting patches or because upstream is hideously old and no one is really doing releases). If there is any time when some x-distro guys want to discuss any options we might have in this regard I'd be willing to participate. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Question] How to specify LimitCORE=infinity for all the daemon processes?
'Twas brillig, and Oleksii Shevchuk at 20/02/13 09:53 did gyre and gimble: By default services has infty limit, afaik If you have 25M truncated cores, that's because of systemd-coredump limitation. Feel free to try this patch: http://lists.freedesktop.org/archives/systemd-devel/2013-February/009065.html Or you can configure the journal to not capture coredumps at all, either via a compile time option or a sysctl tweak (kernel.core_pattern I think). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] loopback and dhclient advice please
'Twas brillig, and Reindl Harald at 22/02/13 10:55 did gyre and gimble: Am 22.02.2013 11:21, schrieb lux-integ: On Friday 22 February 2013 10:00:39 Lennart Poettering wrote: DHCP does not apply to the loopback device as the loopback is unconditionally configured to 127.0.0.1, and dynamic configuration is not necessary Thanks for you information concerning the loopback interface. But my question ANDed loopback and dhclient I know that loopback is not related to dhcp. The unanswered part of my question concerned dhclient. Are there unit files for dhclient and if not could you provide suggestions how one would create one? for what? dhclient does not need to be started as service it is startet if a interface configured for dhcp comes up I have seen some people using dhclient as a templated service configured to trigger when the device shows up (e.g. After=sys-subsystem-net-devices-eth0.device + Requires=sys-subsystem-net-devices-eth0.device). This kind of setup might be desirable in very basic custom configurations where the full network initscripts are not needed. But to answer the OP's question, no, there are not units for dhclient that are shipped with systemd. You may find some examples of units for dhclients that some people have created for their custom setups however. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 12 commits - src/core src/shared
'Twas brillig, and Andrey Borzenkov at 28/02/13 03:10 did gyre and gimble: В Wed, 27 Feb 2013 17:27:16 -0800 (PST) mich...@kemper.freedesktop.org (Michal Schmidt) пишет: New commits: commit 03b717a3c4f9348807fc56e7a7d711d72d4ec0cb Author: Michal Schmidt mschm...@redhat.com Date: Thu Feb 28 00:03:22 2013 +0100 core/manager: print status messages about running jobs Sometimes the boot gets stuck until a timeout hits. The usual timeouts are on the order of minutes, so users may lose patience. Print animated status messages telling the names of units with running jobs to make it easy to see what systemd is waiting for. The animation looks cooler with a shorter interval, but 1 s is OK and should not be too hard on slow serial console users. That's really cool and fixes one of the most frequent complaints about systemd from end-users - lack of information when something goes wrong during boot. Yup, very nice indeed :) How does it integrate with Plymouth? IThat most users will have it and not plain console. Good question :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On(Resume|suspend|hibernate) in unit files?
'Twas brillig, and Lennart Poettering at 28/02/13 12:37 did gyre and gimble: On Wed, 27.02.13 22:22, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Hi: There is buggy, legacy software around which simply does not behave properly when faced with resume/suspend/hibernate which is not always practical to modify or fix. Is there any way to have something like ReloadOnResume=[true|false] StopOnSuspend=[true|false] Or some other mechanism provided by systemd/logind that does not require to use the ugly /usr/lib/systemd/system-sleep/ hooks ? My recommendation would be to fix the software in question. I mean, we will provide compatibility with older software, but we are very conservative on adding hacky work-arounds for broken software, especially if no such hack existed in the solutions that were used before systemd. FWIW, while I'm in total agreement with what you say and the resolution, the pm-utils hooks are what was used before systemd so there technical was such a hack that existed in the solutions that were used before systemd. I remember seeing various hooks here to e.g. shut down mysql and restart it again and such like things. That particular example hasn't been needed for me for ages, but I'm sure there are other examples that might be more legitimate. That said, I think Fred had patches that are applied in Suse to read these pm-utils hooks anyway, so that might be what Cristian needs? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --revert option to show the newest lines first
'Twas brillig, and Mantas Mikulėnas at 28/02/13 18:09 did gyre and gimble: Doesn't coreutils tac already do this? Yes but that would require piping the entire output through tac which could be really inefficient. If this patch is committed, please don't forget to fix the subject!! s/--revert/--reverse/ Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] coverity patches
For the benefit of the list, these patches were posted separately and have been applied (if my fuzzy head has read the list properly!). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About “systemd-cat --priority=0”
'Twas brillig, and Michal Schmidt at 08/03/13 11:10 did gyre and gimble: Dne 8.3.2013 10:57, Yan Lei napsal(a): Sorry for troubling you, but I have got an issue to confirm with you. My issue is when I use the following command: systemd-cat --priority=0 echo hello Nothing logged into the journal, and the exit code is 141. I wonder whether it is a bug or it just work as expected. Looks like a bug to me. Fixed now in git: http://cgit.freedesktop.org/systemd/systemd/commit/?id=e14ddf1cac12f91685cbd5dac6c5127f8cf87863 In your commit message you said: BTW, I'm not sure why we allow priorities up to 999, but I'm leaving this be for now. Technically only values up to 998 would be allowed due to the same range checking problem you fixed. Whatever the reason for the large levels, it's perhaps an oversight that 999 is not allowed? Likely not an issue except in one backwater logging system buried in a basement somewhere :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Specifier support for Alias
'Twas brillig, and Markus Rathgeb at 09/03/13 08:20 did gyre and gimble: Hi! I am using a NAS and want to create .mount and .automount service files for the shared. The service files differs only by the name of the share and mount target. So I thought I use a @ template for that. I created a file mnt-NAS@.automount (same for .mount with different content, but the same Alias logic): === [Unit] Description=Automatically mount the NAS share %I [Install] Alias=mnt-NAS-%I.automount [Automount] Where=/mnt/NAS/%I === If I use systemctl enable the symlink is not greated as expected: ln -s '/etc/systemd/system/mnt-NAS@.automount' '/etc/systemd/system/mnt-NAS-%I.automount' What have I to change? Or is this not supported? Why? Currently I believe all mount units have to be named after their mountpoint, so using template units for mounts just isn't possible. Regarding specifier support in Alias, this is somewhat relevant the discussion in the thread [PATCH] units: Make getty@.service install rule generic not identical by any means but related. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Underlinking in libsystemd-login
'Twas brillig, and Canek Peláez Valdés at 13/03/13 03:40 did gyre and gimble: On Tue, Mar 12, 2013 at 9:08 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Mar 11, 2013 at 03:25:48PM +0100, Lennart Poettering wrote: On Sun, 10.03.13 11:29, Canek Peláez Valdés (can...@gmail.com) wrote: In Gentoo we are seeing the following failure with programs linking agains libsystemd-login, they all fail with: /usr/lib64/libsystemd-login.so: undefined reference to `sd_id128_to_string' /usr/lib64/libsystemd-login.so: undefined reference to `sd_id128_get_boot' /usr/lib64/libsystemd-login.so: undefined reference to `sd_id128_get_machine' collect2: ld returned 1 exit status or similar. More info in the bug 62085: https://bugs.freedesktop.org/show_bug.cgi?id=62085 The following patch fixes the issue (at least with udisks, gnome-session, gdm, and gnome-shell), but I'm not sure is the correct solution. Asking here for guidance. Hmm, so the actual sources of the library itself, i.e. sd-login.c don't use any the sd_id128_xyz functions, and hence we shouldn't apply your patch. Instead, since d848b9cbfa0ba72 the id128 stuff is pulled in by specifier.c which is part of the convenience library libsystemd-shared.so. Or in other words, we currently have a nice dep loop in place where -shared.so and -id128.so use each other's functions. We might want to split out the id128 stuff from specifier.c again? Zbigniew? It seems to be enough to move the specifier.[ch] stuff to libsystemd-units. I'm pushing a fix along those lines now. Could you please report the commit here so I can test it? I'm not subscribed to -commits. The -commits list is just a convenience mainly for reviewers, but you can also just look on the cgit web interface and find the commit very easily if you know what to expect and when it was done etc. In this case it took only 10 seconds for me to spot: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ee465038ce86bd3a0f21d5e2723393ff9d78855d Likely a less time than it took to send the email asking for the sha1 :) All the best! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-fsck-root.service without initrd prints ugly message on clean fsck
Hi, As I'm doing some initrd-less experiments of late I'm seeing an ugly fsck message pop up on boot. In systemd-fsck-root.service I see: StandardOutput=journal+console which results in: systemd-fsck[116]: /dev/sda2: clean, 435608/1310720 files, 3375994/5242112 blocks being output over the top of plymouth screen (and actually persists over the initial gdm screen when it fades in). While I do get the point of showing this on the console, is there a way we can make it silent in the clean case? Would this be something we'd need push down to all the fsck implementations (i.e. support a -q argument or look for silent on /proc/cmdline) or can we add some kind of fugly heuristic to the systemd-fsck that silently swallows the output if it consists of a single line which has the string : clean, and there is silent on the command line? Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root.service without initrd prints ugly message on clean fsck
'Twas brillig, and Kay Sievers at 13/03/13 11:50 did gyre and gimble:
On Wed, Mar 13, 2013 at 11:29 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
As I'm doing some initrd-less experiments of late I'm seeing an ugly
fsck message pop up on boot.
In systemd-fsck-root.service I see:
StandardOutput=journal+console
which results in:
systemd-fsck[116]: /dev/sda2: clean, 435608/1310720 files,
3375994/5242112 blocks
being output over the top of plymouth screen (and actually persists over
the initial gdm screen when it fades in).
While I do get the point of showing this on the console, is there a way
we can make it silent in the clean case?
Would this be something we'd need push down to all the fsck
implementations (i.e. support a -q argument or look for silent on
/proc/cmdline) or can we add some kind of fugly heuristic to the
systemd-fsck that silently swallows the output if it consists of a
single line which has the string : clean, and there is silent on the
command line?
It should be patched into the fsck tool, not to print clean or any
other messages at all, when all is fine.
I only think the ext stuff does that nonsense; just switch to btrfs. :)
One day, but I'm still paranoid for now!
FWIW, the attached patch seems to work for me, but I'm not sure it'll be
accepted upstream... The change is smaller than it looks, it just wraps
the log output in an if statement that suppresses the message when -a is
supplied.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Author: Colin Guthrie co...@mageia.org
When the filesystem is clean, e2fsck still prints out a clean message
when checking. This can muddy the boot and leak into plymouth/gdm on
silent boots.
This patch simply does not show the clean message when the -a option
is passed to the fsck.
--- e2fsprogs-1.42.7/e2fsck/unix.c.0002 2013-01-22 03:33:35.0 +
+++ e2fsprogs-1.42.7/e2fsck/unix.c 2013-03-13 13:16:52.254482074 +
@@ -421,33 +421,35 @@
}
/* Print the summary message when we're skipping a full check */
- log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
- ctx-device_name,
- fs-super-s_inodes_count - fs-super-s_free_inodes_count,
- fs-super-s_inodes_count,
- ext2fs_blocks_count(fs-super) -
- ext2fs_free_blocks_count(fs-super),
- ext2fs_blocks_count(fs-super));
- next_check = 10;
- if (fs-super-s_max_mnt_count 0) {
- next_check = fs-super-s_max_mnt_count - fs-super-s_mnt_count;
- if (next_check = 0)
+ if (!(ctx-options E2F_OPT_PREEN)) {
+ log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
+ ctx-device_name,
+ fs-super-s_inodes_count - fs-super-s_free_inodes_count,
+ fs-super-s_inodes_count,
+ ext2fs_blocks_count(fs-super) -
+ ext2fs_free_blocks_count(fs-super),
+ ext2fs_blocks_count(fs-super));
+ next_check = 10;
+ if (fs-super-s_max_mnt_count 0) {
+ next_check = fs-super-s_max_mnt_count - fs-super-s_mnt_count;
+ if (next_check = 0)
+next_check = 1;
+ }
+ if (!broken_system_clock fs-super-s_checkinterval
+ ((ctx-now - fs-super-s_lastcheck) = fs-super-s_checkinterval))
next_check = 1;
+ if (next_check = 5) {
+ if (next_check == 1) {
+if (batt)
+ log_out(ctx, _( (check deferred;
+ on battery)));
+else
+ log_out(ctx, _( (check after next mount)));
+ } else
+log_out(ctx, _( (check in %ld mounts)), next_check);
+ }
+ log_out(ctx, \n);
}
- if (!broken_system_clock fs-super-s_checkinterval
- ((ctx-now - fs-super-s_lastcheck) = fs-super-s_checkinterval))
- next_check = 1;
- if (next_check = 5) {
- if (next_check == 1) {
- if (batt)
-log_out(ctx, _( (check deferred;
- on battery)));
- else
-log_out(ctx, _( (check after next mount)));
- } else
- log_out(ctx, _( (check in %ld mounts)), next_check);
- }
- log_out(ctx, \n);
skip:
ext2fs_close(fs);
ctx-fs = NULL;
--- e2fsprogs-1.42.7/tests/f_orphan_indirect_inode/expect.1.0002 2012-07-30 23:41:44.0 +0100
+++ e2fsprogs-1.42.7/tests/f_orphan_indirect_inode/expect.1 2013-03-13 12:46:11.388723938 +
@@ -1,2 +1 @@
-test_filesys: clean, 12/16 files, 21/100 blocks
Exit status is 0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root.service without initrd prints ugly message on clean fsck
'Twas brillig, and Reindl Harald at 13/03/13 17:37 did gyre and gimble: Am 13.03.2013 17:44, schrieb Kay Sievers: On Wed, Mar 13, 2013 at 5:30 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Wednesday, March 13, 2013, Kay Sievers k...@vrfy.org wrote: On Wed, Mar 13, 2013 at 3:17 PM, Reindl Harald h.rei...@thelounge.net wrote: so and what are you guys saying if i explain you that i WANT THIS MESSAGES bedcause I WANT to SEE /dev/sda2: clean, 435608/1310720 files Now, that you ask, I would say: I don't care. :) This is one of those cases where more information isn't actually providing you with useful data. We should print out errors and warnings, but if everything is working as it should, then nobody should care, and it should remain silent. If you do care, then the right solution is to implement some notification mechanism that can be added or is optional, and disabled by default. I'd rather spend my time figuring out how to get fsck issues all the way to admin users instead... That seems much more useful. Right, as always, it is about sane defaults, and clean isn't any sane default to print, ever. If wanted, tools can support --verbose and print all their stuff, but there is no case to clutter the console with nonsense like clean. We don't print OK for all other tools as well so all the green OK messages at boot are existing only in my brain hint: disable rhgb and quiet If you read my original mail again you'll see that this message is showing up for me inside plymouth and gdm screens. This is a graphical boot, it shouldn't clutter that up by printing out console messages over the top. I've explicitly set quiet and splash on the kernel command line, but it's still printed. It provides me with zero useful information - if it was failing then, yes, I'd like to see that, but having some text pop up during my nice graphical boot just looks totally wrong (obviously). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootchart issues on slow hardware
'Twas brillig, and Kay Sievers at 18/03/13 10:42 did gyre and gimble: On Mon, Mar 18, 2013 at 5:06 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Mar 17, 2013 at 02:54:01PM +0100, Kay Sievers wrote: Here is a chart: http://people.freedesktop.org/~kay/bootchart-20130317-1434.svg Rotating media and really cheap hardware looks very sad, and we take like 5 times longer to boot than Windows 8. Why is systemd taking ~5 s, and udev 3 s of cpu time? Maybe there's something wrong here. Unfortunately it's hard to say what udev is waiting That's just the world of slow CPUs and rotating disks. Maybe developers should be forced to hack on such machines only. :) That's likely too cruel. Maybe just hack one day a week on such machines :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] doing something as the last activity on boot
'Twas brillig, and Britton Kerin at 18/03/13 17:49 did gyre and gimble: Hi everyone, I just had my first encounter with systemd and all in all I'm highly impressed. One thing saddened me a bit though: its not obvious what to do if I just want to start a service or do something *after* all the stuff that shipped with ths OS has happened and the system is fully operational. I found some email from long ago stating that systemd devs thought this would not be a sane feature to provide, I don't know if that's true but if it is I don't understand the logic. Whenever I have to go into init systems I always want exactly that. And its always surprisingly painful. This is the #1 use outside of OS devel. context that the init system is going to see, so it seems to me that is should be supported, and probably be the first thing in the manual as well. The primary problem is wanting to do some last only works once. What if several different tasks want to be done last? Then you have to work out whether they can be run in parallel or order them somehow. When you extrapolate this out, it becomes immediately obvious that the simple case - one thing, done last is something that has to be treated quite specially, and it becomes very fragile. If you're not careful a whole bunch of infrastructure has to be put in place and you'll end up with some other, bizarre and strange format for running these late tasks that is akin to inittab or something equally undesirable. It's far, far better to step back and actually think about the task you are wanting to do, encode all that information in a custom unit and then just let systemd deal with it in the most sensible way. You simply add the relevant dependencies and systemd will run your job in as parallelised a way as possible. You can also use Type=idle units if you want your unit to only trigger once all other jobs are done. I've not really seen a solid example when someone has really wanted to do something last that cannot be somewhat rethought and dealt with in a more robust and logical manner. Happy hacking. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] what to depend on to avoid file mtime discontinuities?
'Twas brillig, and Britton Kerin at 18/03/13 17:56 did gyre and gimble: My service needs reasonably continuous mtimes on files, but at the moment there is a big discontinuity soon after boot. There is nothing you can do to rely on this absolutely. The only proper way is to fix the broken assumptions. Of course you can typically get a good enough result (tho' that doesn't make it any more correct, especially twice a year when daylight savings kicks in unless you're on a fixed timezone). There are a number of web pages out there which tell you to put stuff like this: After=syslog.target network.target WantedBy=multi-user.target So this is written somewhat confusingly as these two directives go in different sections [Unit] and [Install] respectively. syslog.target is dead now so you don't need it any longer with any vaguely recent system. network.target is a bit rubbish too as the network is not really a static entity - it can appear to be 99.9% static. network itself has nothing to do with time. In your .service file linked from: /etc/systemd/system/multi-user.target.wants I'm guess I want to be After one of these targets: time-sync.target or systemd-timedated.service Yes, time-sync.target seems best. It's not a guarantee tho'. If there are network issues etc. then time-sync.target will be reached after a timeout if ntp tries and fails to update itself over the network. If the problem rectifies itself later (and this could be e.g. a routing issue totally outside of your server), then the ntp server should try and fix things. Of course most sensible ntp targets try to avoid big jumps and slow or speed the clock up a bit to bring it in line (please correct me if I'm wrong). But if multi-user.target doesn't already depend on them I'm not sure its safe for my target, which is WantedBy multi-user.target, to do so? You are confusing After and WantedBy here. The former is about ordering, the latter is about about grouping. WantedBy just means I want this service to be started when multi-user.target starts It doesn't contain any information about ordering etc. In an ideal world, everything wanted by multi-user.target would all be started in parallel. In practice, we typically want some degree of ordering, and that's what the Before= and After= directives are about. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] Revert build-sys: keep intermediate files
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 20/03/13 18:48 did gyre and gimble: On Wed, Mar 20, 2013 at 02:43:17PM -0400, Colin Walters wrote: On Wed, 2013-03-20 at 15:23 +0100, Jan Engelhardt wrote: This reverts commit v197-230-g652e737, because it broke parallel building. between v197-229 and v197-230; the man/sd_journal_get_data_threshold.3 issue seemed to have been fixed, but the objcopy problem persisted to date. Are you using GNU Make 3.82? If so, see: http://savannah.gnu.org/bugs/?30653 Pulling in that patch fixed the build for me. Note Fedora ships that patch, Debian/Ubuntu are still using 3.81, and if you're using OpenEmbedded they recently applied the patch too. Seems likely. In the make -d output Jan has: Pruning file `systemd'. Finished prerequisites of target file `org.freedesktop.systemd1.Manager.xml'. Must remake target `org.freedesktop.systemd1.Manager.xml'. while `systemd' is still being made. Confirmed two builds of systemd 198 before that patch broke for me, and two builds after that patch worked fine. Thanks for the info :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
'Twas brillig, and Frederic Crozat at 25/03/13 10:14 did gyre and gimble: Le vendredi 22 mars 2013 à 23:53 +0100, Lennart Poettering a écrit : On Thu, 21.03.13 17:04, Frederic Crozat (fcro...@suse.com) wrote: Hi all, in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB Provides can sometime be incorrectly handled (resulting in Failed to add LSB Provides name .service, ignoring: File exists errors), depending on initscript parsing order (if a provides is required by another initscript and this initscript is parsed before the one with the provides). Can you explain the problem in more detail? Not following here. Yes, sorry, I didn't give our test example : Let's say you have two initscripts, A and B: A contains in its LSB header: Required-Start: C and B contains in its LSB header: Provides: C When systemd is parsing /etc/rc.d/, depending on the file order, you can end up with: - B is parsed first. An unit C.service will be created and will be added as additional name to B.service, with unit_add_name. No bug. - A is parsed first. An unit C.service is created for the Required-Start dependency (it will have no file attached, since nothing provides this dependency yet). Then B is parsed and when trying to handle Provides: C, unit_add_name is called but will fail, because C.service already exists in manager-units. Therefore, a merge should occur for that case. Is this explanation perhaps worthy of going in the commit message? It was all very clear when I read this extended explanation but I didn't 100% grok it before :) Also, whitespace/coding style issues. Will fix. Sorry to be a pain, but technically the new, much leaner patch still contains a whitespace/coding style issue :p unit_merge_by_name should not have a space after it before it's parenthesis. Of course it's trivial for someone to do both those things above when merging, but. :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
'Twas brillig, and Belal, Awais at 28/03/13 12:22 did gyre and gimble: Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: *systemd[1]: Found ordering cycle on basic.target/start* *systemd[1]: Walked on cycle path to sockets.target/start* *systemd[1]: Walked on cycle path to dbus.socket/start* *systemd[1]: Walked on cycle path to sysinit.target/start* *systemd[1]: Walked on cycle path to run-postinsts.service/start* *systemd[1]: Walked on cycle path to basic.target/start* *systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start* *systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start* Systemd is running in SysV compatibility mode. The odd thing here for me is once the system finishes booting I can see that dbus.service is up (through systemctl) but ofono and connman are never started although I can start them manually through systemctl. 1. How can such problems be disected and is there a way for knowing the dependency graph? 2. The ordering cycle was broken at dbus.socket/start, why aren't the other services tried out after that? BR, Awais As Frederic already said in his reply, I've found the most common case for ordering cycles is the lack of LSB headers in legacy sysvinit scripts. When there are no LSB headers systemd has to use the number in the symlink (the S??fooo bit) to determine the ordering. These orders frequently cause cycles. Another improvement to the cycle breaking logic could be to somehow boot out non-native units first (ideally non-LSB, followed by LSB, followed by native if sysvinit compatibility is compiled in). It's perhaps not overly clean to implement tho'. The cleanest solution is of course just to migrate away from sysvinit in any shape or form :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent changes to the serial console
'Twas brillig, and Lennart Poettering at 29/03/13 15:32 did gyre and gimble: On Fri, 29.03.13 13:29, Andrey Borzenkov (arvidj...@gmail.com) wrote: serial-getty@.service is used only as template, and it looks like getty-generator always links to (/usr)/lib/systemd: from = strappend(SYSTEM_DATA_UNIT_PATH /, fservice); to = strjoin(arg_dest,/getty.target.wants/, tservice, NULL); It probably should use real unit path for fservice. Hmm, so actually even if you symlink like this, then /etc should override /lib, and the symlink destination path should only be used as last fallback. That's at least the theory, but there might be a bug somewhere... iirc there where problems with that, where aliases of autvt@ didn't get taken into account properly either... Something to look into definitely. Added to TODO list. Hmm, is this changed behaviour from the past. I remember you explaining to me a while back that templated units follow the symlink and use that unit definition, unlike regular units which just check the unit name. Didn't really ever like that logic, but such was the way of things. What you say above seems to suggest that in all cases the actual destination of the symlink doesn't matter at all, it's purely the unit name that counts. Is that the case? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mounting efivars / efivarfs
Hi, Seems on my system, I have to load the module efivars before I can mount my efivarfs (mount -t efivarfs efivarfs /sys/firmware/efi/efivars) Now, systemd should do this magically but for some reason it doesn't do that. If I do not have the efivars module loaded the above mount command fails. No automatic modprobe happens - I suspect this is why systemd fails to mount it. Any thoughts on why it might not be automatically loaded by the kernel when the mount is attempted? Is it simply because it's missing some kind of module alias on the name efivarfs? I guess it would work if it were baked into the kernel itself, but it _should_ really work with a module too... Relevant kernel config: CONFIG_EFI_PARTITION=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=y CONFIG_EFI_VARS=m CONFIG_EFI_VARS_PSTORE=y CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mounting efivars / efivarfs
'Twas brillig, and Greg KH at 09/04/13 00:48 did gyre and gimble: On Tue, Apr 09, 2013 at 12:02:09AM +0100, Colin Guthrie wrote: Hi, Seems on my system, I have to load the module efivars before I can mount my efivarfs (mount -t efivarfs efivarfs /sys/firmware/efi/efivars) Now, systemd should do this magically but for some reason it doesn't do that. You need a newer kernel version that properly exports the efivarfs name to userspace, letting mount know what module to load. The 3.9-rc2 kernel release should have this change in it, so you can either backport the needed patch, or wait for 3.9 to be released. Hope this helps, Thanks Greg, I'll hunt out the appropriate commit. I'm on 3.8.6 here and I suspect we'll stay on that for the release, so will ask our kernel maintainer to include the required support. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mounting efivars / efivarfs
'Twas brillig, and Tom Gundersen at 09/04/13 10:22 did gyre and gimble: On 9 Apr 2013 01:48, Greg KH gre...@linuxfoundation.org mailto:gre...@linuxfoundation.org wrote: On Tue, Apr 09, 2013 at 12:02:09AM +0100, Colin Guthrie wrote: Hi, Seems on my system, I have to load the module efivars before I can mount my efivarfs (mount -t efivarfs efivarfs /sys/firmware/efi/efivars) Now, systemd should do this magically but for some reason it doesn't do that. You need a newer kernel version that properly exports the efivarfs name to userspace, letting mount know what module to load. The 3.9-rc2 kernel release should have this change in it, so you can either backport the needed patch, or wait for 3.9 to be released. I don't think that's enough. It exports the alias, but the mountpoint still won't exist until the module is loaded. For now you'll have to compile the module into your kernel. Matt Flemming recently posted a patch series which fixes the problem, so hopefully that will be in 3.10. Cool, thanks Tom. I think we'll likely just make it a built-in for now rather than a module (at least for the short term). Seems the path of least resistance and solves a couple other issues too. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 70-persistent-net.rules
'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble: On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald h.rei...@thelounge.net wrote: /usr/share/doc/systemd/README.Fedora-18 - A hacky workaround that allows udev to rename network interfaces into kernel's ethX namespace has been re-added. This is to support users who still rely on udev rules such as 70-persistent-net.rules generated in previous Fedora releases to name their network interfaces. Note that the workaround is only temporary and will go away in a future Fedora release __ PLEASE DO NOT remove this mechanism well, you are not creating it since a long time, BUT do not stop use this config file if it is present! Mmm ... if rules file exists in correct directory it of course will be used. Or do you mean to not remove auto-generation of this file? Isn't the mechanism used to shuffle around conflictingly named interfaces gone from udev these days (it is after all racy and buggy). If so then things might not work nicely when processing the old rules. Users should be strongly encouraged to migrate to the persistent network interface names which avoids the design flaws inherent with the previously approach. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 70-persistent-net.rules
'Twas brillig, and Reindl Harald at 11/04/13 11:55 did gyre and gimble: Am 11.04.2013 12:41, schrieb Colin Guthrie: 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble: On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald h.rei...@thelounge.net wrote: /usr/share/doc/systemd/README.Fedora-18 - A hacky workaround that allows udev to rename network interfaces into kernel's ethX namespace has been re-added. This is to support users who still rely on udev rules such as 70-persistent-net.rules generated in previous Fedora releases to name their network interfaces. Note that the workaround is only temporary and will go away in a future Fedora release __ PLEASE DO NOT remove this mechanism well, you are not creating it since a long time, BUT do not stop use this config file if it is present! Mmm ... if rules file exists in correct directory it of course will be used. Or do you mean to not remove auto-generation of this file? Isn't the mechanism used to shuffle around conflictingly named interfaces gone from udev these days (it is after all racy and buggy). If so then things might not work nicely when processing the old rules. Users should be strongly encouraged to migrate to the persistent network interface names which avoids the design flaws inherent with the previously approach. that is all nice in theory in real life there are THOUSANDS of setups with only one ethernet interface there are THOUSANDS of virtual machines with only one network interface there are THOUSANDS of virtual machines with only two NICs and no race-problems there are MANY THOUSANDS of configs and scripts for routing, firewalls and automation on all this machines and only god knows what amount of work and side effects it brings to change this all for zero benefit this are facts from the real life and as much i agree with the race problems i really do not want to change interface names on remote-machines which are not in a datacenter and have no LOM hundrets of kilometers way and so i need a long-term way to have my eth0 and in very few cases eth1 too I accept that rationale and see your point, but the fact that the code is a bad concept is something that should still be strongly discourage. Any scripts that assume names are also broken by design and should really be written better to deal with things more gracefully, although I totally agree that breaking existing setups is bad. But on the other hand I haver personally been locked out of my machine at a data centre and had to endure several hours of downtime as a result of the network interfaces randomly flipping after a reboot, so I do really also want to see the correct design filter through and become best practice and the accepted standard. But regardless, unless the patch to allow renaming is carried locally in the distro for a long time (http://pkgs.fedoraproject.org/cgit/systemd.git/tree/0005-F18-Revert-udev-network-device-renaming-immediately-.patch?h=f18) then eventually the support will have to disappear - but ultimately this is something to discuss with your distro. That said, it is interesting that Fedora, Suse and ourselves at Mageia, all carry this patch in our releases (although it's gone from F19 looking at the git). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 70-persistent-net.rules
'Twas brillig, and Reindl Harald at 11/04/13 12:10 did gyre and gimble: Am 11.04.2013 13:02, schrieb Tom Gundersen: On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald h.rei...@thelounge.net wrote: there are THOUSANDS of virtual machines with only two NICs and no race-problems In the case where no renaming is done at all, and it JustWorks, then you can still disable persistent interface naming and everything will be as before. In the case where you have rules to rename the interfaces within the kernel namespace, you need to update the configuration (at least in the long-term; the change has happened upstream, but don't know what Fedora intends to do downstream) and because HERE IS UPSTREAM i ask here to not remove the code for 70-persistent-net.rules because it just works in many cases even with rename It was removed a long time ago aready... Back in 187 or 188 IIRC (certainly around that time). So the question is really whether it should be added back in to allow this kind of broken-by-design setup (albeit with a lot of THIS IS A HORRIBLE HACK error messages thrown in to annoy people in their log files as punishment!)? Personally, I'd be happy to be a little pragmatic here (the code is not *that* hard to maintain), but I do also prefer the fix things with the right design philosophy generally. Ultimately the decision lies with Kay, so he's the one you have to convince! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 70-persistent-net.rules
'Twas brillig, and Kay Sievers at 11/04/13 12:51 did gyre and gimble: On Thu, Apr 11, 2013 at 1:46 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Should we then consider trying to push a new default name scheme into the kernel side such that they come up as eth-ng0 etc. by default allowing any userspace stuff to rename them to eth1 or whatever without so much likelihood of such conflicts. That would be the only manageable option if such rules would be need to make working. The kernel could have a parameter to reserve eth0-99, or so and the first interface it creates would be eth100. Yeah an increased starting index would likely make more sense than a separate naming scheme (and be less controversial). A compile time option + a command line override would likely cover all bases :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start and stop actions of device units
'Twas brillig, and Léo Gillot-Lamure at 13/04/13 11:11 did gyre and gimble: Hi. Would it be possible to bind something to the start and stop actions of a device unit ? I've got a device (a hard drive) that I can programmatically plug/unplug using commands such as echo '0 0 0' /sys/class/scsi_host/host1/ scan and echo 1 /sys/devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete. The goal is reducing noise. It would be nice to bind these commands in the device unit itself so that other units needing it can start it by themselves, etc. So I think this should just be a matter of creating a .service unit with appropriate ExecStart/Stop directives and then add a BindTo= directive to bind it to the device. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [systemd-commits] Makefile.am src/bootchart - Make bootcharts go to the journal
'Twas brillig, and Kok, Auke-jan H at 16/04/13 00:33 did gyre and gimble: FYI - this is a first pass to putting the bootcharts into the journal, exactly as coredump does. Ultimately, I will probably make bootcharts not go to disk other than the journal by default. A single one-liner can be used to get the latest bootchart automatically: $ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518 --field=BOOTCHART bootchart.svg Just out of curiosity, what is the rational behind doing this? I think it's really cool that we can store arbitrary things in the journal, but I have concerns about storing potentially large stuff in there. The bootchart is likely not that big, but especially with coredumps (which has patches now thankfully) a small period of dump frenzy can fill up your logs and cause rotation. This could be exploited at some point in the future by an attacker to cover their tracks making you think some software had just gone haywire when reviewing your (rotated) journals. Was there anything particularly wrong or problematic previously with writing out to a file? Other than a log of previous boots, what advantage does it have to keep them in the journal? I'm mostly playing devils advocate here. I do kinda like the fact it's in there personally, but then I like shiny things. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 19:48 did gyre and gimble: On Mon, Apr 15, 2013 at 08:36:33PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 15, 2013 at 02:31:56PM -0300, Chir0n wrote: # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal # systemd-nspawn -bD /srv/mycontainer sudo nsenter -t $PID -m -u -i -n -p /bin/bash Hm, if I say 'halt' in this bash window, I see bash-4.2# halt bash-4.2# [1] + 14306 suspended (signal) sudo nsenter -t 13221 -m -u -i -n -p /bin/bash and the container's init hangs after 'All filesystems unmounted.'. Only when I do 'fg', halt resume and systemd-nspawn quits. Apparrently only happens rarely (1/5 so far). What's going on? Isn't halt meant to, well, halt? Perhaps it behaves differently under nspawn but I thought that was the primary difference between halt and poweroff Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot Service on Select Motherboard Only
'Twas brillig, and systemdki...@yopmail.com at 15/04/13 23:03 did gyre and gimble: Question: how to boot ntpd.service on one PC and not others from the same USB stick. Network Time Service computes clock tweaks for a motherboard. The idea is to run it on just one motherboard brand/model, or maybe serial number. If the USB stick boots another PC, then ntpd is bypassed, because the recorded values on disk are irrelevant and wrong. The issues may well have more to do with udev than systemd, but I'd appreciate guidance. It would be nice to use stock ntpd.service, but I don't know if systemd can manage, or how a custom service may look if not. Looks like something you could detect with a udev rule somewhere (i.e. matching on some hw identifier) which in turn spawns the systemd unit. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] journal: get rid of LINE_MAX in sd_journal_printv*()
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 22:30 did gyre and gimble: Hm, I've now read the wikipedia page ;), and I see that it's not possible. So I guess that's not a valid concern. Wikipedia /Wi-key-pee-dia/ Noun 1. Repository of erroneous history information 2. Cyber-bullying web portal 3. The birthplace of the socially engineered buffer overflow where fake articles on defensive programming techniques lured developers into a false sense of security. :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service unit issue: starts manually but doesn't start on boot
'Twas brillig, and Peter Li at 19/04/13 07:06 did gyre and gimble: Greetings, I hope this issue is familiar to someone here. I wrote a unit file for a service called wsgw. It starts fine with `systemctl start wsgw`, and `systemctl enable wsgw` goes smoothly, but the service doesn't start on boot. My only diagnostic so far has been running `systemctl status wsgw`. When I do this after a boot, I get the following: When you say after a boot, it would appear to be at least 1 hour after you booted (or perhaps this is some quirk due to system clocks) wsgw.service - WebSockets Gateway for pianod Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled) Active: inactive (dead) since Thu, 18 Apr 2013 21:06:37 -0700; 1h 0min ago See 1h ago :) The fact that this is listed here with a time means that systemd *did* start it but it exited... Process: 874 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES (code=exited, status=0/SUCCESS) And here you can see that it exited with code 0 (which generally means No error). When I then run `systemctl start wsgw; systemctl status wsgw` I get: wsgw.service - WebSockets Gateway for pianod Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled) Active: active (running) since Thu, 18 Apr 2013 22:09:40 -0700; 7ms ago Main PID: 2565 (wsgw) CGroup: name=systemd:/system/wsgw.service └ 2565 /usr/sbin/wsgw -p 8000 pianod,localhost,4445,text I suspect that on boot the network or name resolution is not available and your service is started too soon. One thing I notice between the failed-on-boot and succeeded-on-manual-start cases is that the environment variables appear to be unsubstituted in the failed-on-boot case. But of course, one looks like it is reprinting the ExecStart line, and one looks like it's listing the actual command for the successfully running process, so this difference may be expected. Yes, that's why they are different. I have confirmed that executing the wsgw with no arguments or blank arguments does cause an exit with status 0. It seems like lots of invalid arguments all produce exits with status 0 actually, so probably I should talk to the main developer about making these exit codes more helpful. I suspect it will also exit if there is no network ready or similar, but don't know for sure. Also the timestamp on the failed status is wrong; it's an hour earlier than it should be. Ahhh :) Ignore my earlier comment then. I suspect this is just related to the clock configuration and time jumps at some point in early boot when those settings are loaded. I have another service with a very similar setup that doesn't have this issue. Links to the two unit files and the EnvironmentFile for each (wsgw is the one with the issue, pianod is very similar but works on boot): http://svn.deviousfish.com/wsgw/contrib/wsgw.service In this case there is no dependency on network. So unless the binary is able to do the right thing with network devices coming and going (it should as that's the correct behaviour in these dynamic days, but it's highly unlikely it does because very few applications are doing it right!) You should likely have a After=network.target in your unit (After=syslog.target is not needed in recent systemd's but F17 is quite old now so it may still need it). You may also need to do some kind of wait online thing to delay network.target until you have a working network - Network manager ships such a unit which just needs to be enabled. I've run `systemd --test --system --unit=multi-user.target` and compared the wsgw and pianod sections of output and no significant differences jump out at me. Perhaps pianod doesn't need the network? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
'Twas brillig, and Josh Triplett at 22/04/13 22:53 did gyre and gimble: On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. From what I gather what you're trying to solve here is a packaging problem - i.e. that multiple packages may have a requirement for a given user to exist and that if said packages are removed, the user should disappear again? If that is the case, then shouldn't the code actually be part of a packaging helper script rather than managed by a daemon? Also, if there is a .d folder setup here who owns those files? e.g. if I have postfix and cyrus-imapd packages, both will want the mail user. In that case who owns the /usr/lib/passwd.d/news file? They kinda both do need to provide that file, but that's wrong in and off itself - you'd be better creating a structure for this. Also the nothing uses the UID or GID anymore test is a bit hard is it not? I mean we'd have to check all file ownership and ACL entries on all mounted filesystems would we not? Sounds like a bad idea to me. All in all I still thing this is better handled by packaging helper scripts. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
'Twas brillig, and Andrey Borzenkov at 17/04/13 18:01 did gyre and gimble: В Wed, 17 Apr 2013 17:31:14 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 17.04.13 17:20, Jan Engelhardt (jeng...@inai.de) wrote: On Wednesday 2013-04-17 16:42, Lennart Poettering wrote: On Wed, 17.04.13 06:58, Jan Engelhardt (jeng...@inai.de) wrote: Well, the current logic is that we suspend when the lid is closed,[...] Lid switch inhibitor locks are currently per-VT, i.e. a lock taken by GNOME is considered irrelevant if you switch away from GNOME.[...] So in order to make sure the lid switch suspend works fine even when you happen to switch away from GNOME logind will handle it then. That reasoning is perfectly fine; the problem is that logind acts upon a physical lid state change from the distant past. Well, it is level-triggered, not edge-triggered. If the lid is closed and a lock released we immediately act and suspend. That's the only reliable and safe way to do that. One problem is, it breaks existing behavior and quite badly. How users are supposed to start inhibitors on ttyX the very moment they switch to it? It probably needs to be more compatible with exiting behavior by default. I remember something very similar recently ... ah, here it is http://lists.freedesktop.org/archives/systemd-devel/2013-March/009988.html Does this mean if: 1. I use Gnome. 2. I have external monitor attached. 3. I close the lid because I don't use my laptops screen, just the external one. 4. I switch to a VT 5. My machine is insta-suspended? If so then I concur that it needs handled a bit better! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC PATCH] journal: Set the default keep free value to 15% (up from 5%)
As some SSDs are still seeing performance degredation when
reaching 85% usage the default value of 5% seems a little low.
Set this to 15% by default.
---
So I'm really not sure or educated enough about this one,
but we're recently had a user complain about the disk space
used by the journal.
I argued that the defaults were automagic and this should be
fine generally and even if it does use more disk space by default,
it should clear itself out automatically when under pressure.
One comment in reply to my argument mentioned SSD performance. While
this is arguably something that should be fixed elsewhere, should
we be more concervative with things and leave say, 15% free by default?
Col
man/journald.conf.xml | 2 +-
src/journal/journal-file.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 0b9de65..6d54c94 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -246,7 +246,7 @@
configured in
varnameSystemMaxUse=/varname and
varnameRuntimeMaxUse=/varname is
-available. Defaults to 5% of the size
+available. Defaults to 15% of the size
of the respective file
system. varnameSystemMaxFileSize=/varname
and
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index a44e126..bfe2951 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -2769,7 +2769,7 @@ void journal_default_metrics(JournalMetrics *m, int fd) {
if (m-keep_free == (uint64_t) -1) {
if (fs_size 0) {
-m-keep_free = PAGE_ALIGN(fs_size / 20); /* 5% of file
system size */
+m-keep_free = PAGE_ALIGN(fs_size * 3 / 20); /* 15% of
file system size */
if (m-keep_free DEFAULT_KEEP_FREE_UPPER)
m-keep_free = DEFAULT_KEEP_FREE_UPPER;
--
1.8.1.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] %i/%I instance expansion in ExecStartPre ?
'Twas brillig, and d...@sent.com at 01/05/13 16:56 did gyre and gimble: hi zbigniew On Wed, May 1, 2013, at 08:32 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, May 01, 2013 at 08:29:57AM -0700, d...@sent.com wrote: Is %i/%I expansion in ExecStartPre possible? and/or have I misconfigured something here? It's expressly forbidden to use specifiers in the binary name. ok. so, is there some other, clever way to use instances AND reference an instance-specific ExecStartPre=... ? i'm thinking maybe passing an instance expansion variable to a statically-named script? something like ExecStartPre=/etc/openvpn/up.general.script %I ? Is *THAT* allowed (I'm looking in docs for the details of these prohibitions ...) The rules for ExecStartPre and ExecStart are the same so you can use the %i/%I specifiers in the arguments - that's what they were designed for :) Looking at man systemd.service and checking the ExecStart section it says: The command line accepts % specifiers as described in systemd.unit(5). Looking at that it says: To refer to the instance string from within the configuration file you may use the special %i specifier in many of the configuration options. Other specifiers exist, the full list is: So granted, this isn't clear. There are other comments that state the binary name must be a full absolute path, but some cross reference here wouldn't be a bad idea. Note I'm also just checking my patched up 195, not current head so this may have been addressed already. Documentation patches always welcome :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should systemd-udev-settle.service have an [Install] section?
'Twas brillig, and Michael Biebl at 03/05/13 20:52 did gyre and gimble: 2013/5/3 Kay Sievers k...@vrfy.org: On Fri, May 3, 2013 at 7:18 PM, Michael Biebl mbi...@gmail.com wrote: seeing that systemd-udev-settle.service is not enabled by default (as it's mostly a workaround for broken software), shouldn't we at least add an [Install] section, so it *can* be enabled easily by the administrator if needed? We just removed that a while ago because broken services should rather pull it in actively. It should not be enabled globally without users needing it. ok, fair enough. It should work fine to add that back in a distro patch, but we do not want to ship that upstream as the model is really too broken to support. Yeah, I guess we'll have to add that back in the Debian package as long as we ship packages which are SysV only and so don't have a way to pull that service in. IIRC there were some suse patches that added support for X-Systemd-Requires: LSB headers that allowed sysv scripts to do that... that would probably be cleaner as it avoids manual intervention to configure the system correctly. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fedora NFS systemd units
package? Perhaps with no [Install] rule or one that makes sense in isolation if it can be sensibly used separately from nfs. nfs-mountd.service:[Unit] nfs-mountd.service:Description=NFS Mount Daemon nfs-mountd.service:BindTo=nfs-server.service nfs-mountd.service:After=nfs-server.service nfs-mountd.service:[Service] nfs-mountd.service:Type=forking nfs-mountd.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS nfs-mountd.service:StandardError=syslog+console nfs-mountd.service:[Install] nfs-mountd.service:WantedBy=nfs.target The variable name here ends in OPTS, but all the others end in ARGS. Consistency aids understanding and this is already confusing for me, so every little helps!! nfs-blkmap.service:[Unit] nfs-blkmap.service:Description=pNFS block layout mapping daemon nfs-blkmap.service:Wants=var-lib-nfs-rpc_pipefs.mount nfs-blkmap.service:Requires=var-lib-nfs-rpc_pipefs.mount nfs-blkmap.service:[Service] nfs-blkmap.service:Type=forking nfs-blkmap.service:StandardError=syslog+console nfs-blkmap.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS nfs-blkmap.service:[Install] nfs-blkmap.service:WantedBy=multi-user.target No real comment here other than I am left still unsure if I need to manually enable this or not and under what circumstances I should care etc. nfs-lock.service:[Unit] nfs-lock.service:Description=NFS file locking service. nfs-lock.service:Requires=rpcbind.service network.target nfs-lock.service:After=network.target named.service rpcbind.service nfs-lock.service:Before=remote-fs-pre.target nfs-lock.service:[Service] nfs-lock.service:Type=forking nfs-lock.service:StandardError=syslog+console nfs-lock.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-lock.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig nfs-lock.service:ExecStart=/sbin/rpc.statd $STATDARG nfs-lock.service:# Make sure lockd's ports are reset nfs-lock.service:ExecStopPost=-/sbin/sysctl -w fs.nfs.nlm_tcpport=0 fs.nfs.nlm_udpport=0 nfs-lock.service:[Install] nfs-lock.service:WantedBy=multi-user.target No comment here really. The only thing I would say is that rpcbind.target also exists... should this be used as a higher level After= (rather than rpcbind.service) or should we be aiming to kill rpcbind.target in the long term? nfs-secure-server.service:[Unit] nfs-secure-server.service:Description=Secure NFS Server nfs-secure-server.service:Requires=var-lib-nfs-rpc_pipefs.mount nfs-server.service nfs-secure-server.service:After=syslog.target var-lib-nfs-rpc_pipefs.mount nfs-server.service nfs-secure-server.service:[Service] nfs-secure-server.service:Type=forking nfs-secure-server.service:StandardError=syslog+console nfs-secure-server.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-secure-server.service:ExecStart=/usr/sbin/rpc.svcgssd $RPCSVCGSSDARGS nfs-secure-server.service:[Install] nfs-secure-server.service:WantedBy=multi-user.target nfs-secure.service:[Unit] nfs-secure.service:Description=Secure NFS nfs-secure.service:Requires=var-lib-nfs-rpc_pipefs.mount nfs-secure.service:After=syslog.target var-lib-nfs-rpc_pipefs.mount nfs-secure.service:[Service] nfs-secure.service:Type=forking nfs-secure.service:StandardError=syslog+console nfs-secure.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-secure.service:ExecStart=/usr/sbin/rpc.gssd $RPCGSSDARGS nfs-secure.service:[Install] nfs-secure.service:WantedBy=multi-user.target Only comment here is that it is unclear from the unit names what these actually do and how they interoperate. Do I need to enable both for things to work? If so why are they not using Requires/BindTo like the other units? If they work independently (perhaps one is server and one client?), then the descriptions need to be adjusted I think. All in all, I think there is scope to tidy these up and make them better. Adding man pages and Documentation= directives would also help a lot. Happy to help out here if I can get some feedback on some of the points above. Many thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question regarding Also= in [Install]
From the man page: Additional units to install when this unit is installed. If the user requests installation of a unit with this option configured, systemctl enable will automatically install units listed in this option as well. What also happens however is that it if systemctl disable is called it will also disable those units (certainly in my 195+patches build tho' I can't see anything obvious in git what would fix this). The docs imply it is one way and to actually be useful it's also sensible to have this one way (as otherwise you may as well uses BindTo and skip the whole [Install] section in one of the units). Any thoughts? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 203
'Twas brillig, and Lennart Poettering at 07/05/13 01:41 did gyre and gimble: This is probably a good release to synchronize a distribution on. For example, it is our goal that this is the version we will include in Fedora 19, more or less. You said that about 195 and then promptly shipped newer versions in Fedora there after - ourselves and suse listened to that previous advice any synchronised on that version for the ease of maintainability, but that was somewhat scuppered when newer versions showed up in Fedora instead. Such is the way of life, but by the sounds of upcoming changes, it looks like you might genuinely stick with 203 this time :p Either way, good work :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
'Twas brillig, and Steve Dickson at 08/05/13 11:58 did gyre and gimble: On 06/05/13 05:27, Colin Guthrie wrote: Hi, Just trying to work out a few problems on our (Mageia's) NFS packages. As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. nfs-server.service:[Unit] nfs-server.service:Description=NFS Server nfs-server.service:Requires=proc-fs-nfsd.mount var-lib-nfs-rpc_pipefs.mount rpcbind.service nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service nfs-rquotad.service nfs-server.service:After=network.target named.service nfs-server.service:[Service] nfs-server.service:Type=oneshot nfs-server.service:RemainAfterExit=yes nfs-server.service:StandardError=syslog+console nfs-server.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-server.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig nfs-server.service:ExecStartPre=/usr/sbin/exportfs -r nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT nfs-server.service:ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig nfs-server.service:ExecStop=/usr/sbin/rpc.nfsd 0 nfs-server.service:ExecStopPost=/usr/sbin/exportfs -f nfs-server.service:[Install] nfs-server.service:WantedBy=multi-user.target This is the main server unit. It requires the idmap, mountd and rquotad services. It has After=named.service. Should this not be After=nss-lookup.target instead? Bind/named might not be the only thing that does name lookups after all and nss-lookup.target is meant to encapsulate this does it not? (e.g. ldap could factor in here). I didn't know a nss-lookup.target existed... would that be better than After=named.service? It's more generic. So if things other than bind provide name lookups they should hold up nss-lookup.target to allow for such ordering. It's not failsafe, but it's likely a better fit and named.service directly IMO (others please feel free to correct me here). nfs-idmap.service:[Unit] nfs-idmap.service:Description=NFSv4 ID-name mapping daemon nfs-idmap.service:BindTo=nfs-server.service nfs-idmap.service:After=nfs-server.service nfs-idmap.service:[Service] nfs-idmap.service:Type=forking nfs-idmap.service:StandardError=syslog+console nfs-idmap.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-idmap.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS nfs-idmap.service:[Install] nfs-idmap.service:WantedBy=nfs.target This unit is bound to nfs-server so it will follow it's start/stop cycle. Yet it is also wanted by nfs.target. What purpose does nfs.target actually serve here? It was request from https://bugzilla.redhat.com/show_bug.cgi?id=769879 Its not clear why a nfs.target is needed either but it does not break anything so I went with it.. Yeah, but the current units are quite different from the ones submitted in that bug. All of the ones from the bug have WantedBy=nfs.target. In your packages git repo http://pkgs.fedoraproject.org/cgit/nfs-utils.git/tree/ most units have WantedBy=multi-user.target instead, along with various other modifications. While some modifications are good, the confusion for me now lies in what needs to be enabled when etc. FYI, here are my tidyups (which should mostly apply to your files I think): http://svnweb.mageia.org/packages?view=revisionrevision=412429 http://svnweb.mageia.org/packages?view=revisionrevision=412433 The main bit is removing the option from sysadmins for components they shouldn't need to care about (i.e. removing several [Install] sections). Systemd will start them automatically when required and the sysadmin doesn't have to get the magic recipe to make things work). I think this gets them in a better state, but some work is still needed to make it first class and as automatic as our previous solution (more below). Ditto for the mountd and rquotad units which are similarly structured. Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means nobody. No, As (I believe) f17 rpc.idmapd is no longer needed on the client. The kernel now uses the nfsidmap(5) command to to do the idmapping. Ahh that might be a difference between you and us then I guess. I believe we still require it (we certainly did in Mageia 2), but perhaps not. Will have to investigate. My changes above assume it's needed, but it would be trivial to leave it out (basically just remove PartOf=nfs.target and add BindTo=nfs-server.service in nfs-idmap.service and remove the Require=nfs-idmap.service from nfs.target and add Require=nfs-idmap.service to nfs-server.service - all assuming
Re: [systemd-devel] Service is ignoring dependencies (suse)
'Twas brillig, and Chad Anonymous at 09/05/13 20:13 did gyre and gimble: I have an issue where the postgresql.service is being started and does not appear to be obeying the dependency ordering that is specified using a Before= entry that is in another oneshot service file. After turning on systemd debug it appears that the postgresql.service is being enqueud with the ignore-dependencies setting. I have no idea where this is coming from as it is not explicitly set anywhere that I can find. Does systemd implicitly do this in certain scenarios? systemd log: May 9 14:33:01 host-1 systemd[1]: Trying to enqueue job postgresql.service/start/ignore-dependencies I could be wrong but I believe OpenSuse has patches to their wrapper scripts which call systemctl with --ignore-dependences. So i'd guess some other script in the startup process is calling some generic wrapper to start prostgres or something similar to that. I doubt this is an upstream issue tho' (tho' some suse folks will hopefully see here and answer - added it to the subject for better exposure) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shell / systemd config files
'Twas brillig, and James Buren at 20/05/13 18:28 did gyre and gimble: Files such as /etc/machine-info have an incompatibility with systemd in regards to how it writes and/or parses them. Take the following sample: PRETTY_HOSTNAME=\'\\$\`\\ Systemd will translate this to: '$`\ However, the shells bash and dash will translate this to: \'$`\ So, it appears to be that systemd is escaping single quotes when the shells themselves do not honor it for single quotes here. Thoughts for a solution? I ask because I have to write some systemd config files for a distro installer, and cannot use hostnamectl yet. AFAIUI, it's not meant to be 100% shell compatible anyway, so I suspect the currently behaviour is as intended and will remain. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shell / systemd config files
'Twas brillig, and Andrey Borzenkov at 21/05/13 11:26 did gyre and gimble: On Tue, May 21, 2013 at 1:11 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and James Buren at 20/05/13 18:28 did gyre and gimble: Files such as /etc/machine-info have an incompatibility with systemd in regards to how it writes and/or parses them. Take the following sample: PRETTY_HOSTNAME=\'\\$\`\\ Systemd will translate this to: '$`\ However, the shells bash and dash will translate this to: \'$`\ So, it appears to be that systemd is escaping single quotes when the shells themselves do not honor it for single quotes here. Thoughts for a solution? I ask because I have to write some systemd config files for a distro installer, and cannot use hostnamectl yet. AFAIUI, it's not meant to be 100% shell compatible anyway, According to man machine-info, it is. The basic file format of machine-info is a newline-separated list of environment-like shell-compatible variable assignments. It is possible to source the configuration from shell scripts Mea culpa! I guess this information slightly conflicts with the various other places where environment-like stuff is done (e.g. when processing the EnvironmentFile= stuff where there are certain things that are not quite the same as shell (e.g. continuation support IIRC the discussion about that not t long ago). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: Predictable Network Interface Names
'Twas brillig, and Ian Pilcher at 22/05/13 06:31 did gyre and gimble: On 01/08/2013 12:27 PM, Lennart Poettering wrote: On Tue, 08.01.13 12:19, Ian Pilcher (arequip...@gmail.com) wrote: Will there still be a way to turn this off from the kernel command line? (I don't see anything on the wiki page.) biosdevname had this, and we have been thinking of adding this for this too, but so far it doesn't exist. I have now added this to the TODO list so that we don't forget. Did this ever get implemented? Fedora 19 has predictable interface names turned on, and I'm really not looking forward to having to clean up the anaconda-created ifcfg- file(s) every time I do a new install from now on. I've Googled, but come up empty on any command-line options that affect this feature. Looking at the rules in git: http://cgit.freedesktop.org/systemd/systemd/tree/rules/80-net-name-slot.rules yes: net.ifnames=0 Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: Predictable Network Interface Names
'Twas brillig, and Ian Pilcher at 22/05/13 06:31 did gyre and gimble: On 01/08/2013 12:27 PM, Lennart Poettering wrote: On Tue, 08.01.13 12:19, Ian Pilcher (arequip...@gmail.com) wrote: Will there still be a way to turn this off from the kernel command line? (I don't see anything on the wiki page.) biosdevname had this, and we have been thinking of adding this for this too, but so far it doesn't exist. I have now added this to the TODO list so that we don't forget. Did this ever get implemented? Fedora 19 has predictable interface names turned on, and I'm really not looking forward to having to clean up the anaconda-created ifcfg- file(s) every time I do a new install from now on. I've Googled, but come up empty on any command-line options that affect this feature. Looking at the rules in git: http://cgit.freedesktop.org/systemd/systemd/tree/rules/80-net-name-slot.rules yes: net.ifnames=0 Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatic Reboot Protocol
'Twas brillig, and systemdki...@yopmail.com at 26/05/13 06:29 did gyre and gimble: Jan Alexander Steffens, So in this timer, where/how apply reboot.target, or else tell systemd to invoke? Thx -- # /etc/systemd/system/nightjanitor.timer [Unit] Description=Nightly wee-hours heartbeat [Timer] OnCalendar=*-*-* 01:23:45 Unit=nightjanitor.service [Install] WantedBy=multi-user.target -- # /etc/systemd/system/nightjanitor.service [Unit] Description=Nightly chores [Service] Type=simple ExecStart=/etc/systemd/system/nightjanitor.sh -- #!/usr/bin/env bash # /etc/systemd/system/nightjanitor.sh set -e # do system stuff like backup # and house-clean generally, # then REBOOT as final step Normally calling systemctl in a script is fine, but if you call systemctl in a script as triggered by another unit it will typically wait for the job to complete. If the job cannot complete due to waiting for the job Perhaps use of the systemctl --no-block start reboot.target would work and allow your unit to exit happily and thus not block? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatic Reboot Protocol [SOLVED]
'Twas brillig, and Kok, Auke-jan H at 31/05/13 06:27 did gyre and gimble: You can likely create a timer unit, and start that once... That's the premise he started with, but it seems to cause a sort of deadlock... See the first message in the thread. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build option to disable systemd-tmpfiles services
'Twas brillig, and Umut Tezduyar at 02/06/13 10:09 did gyre and gimble: How do you attach patches to the email thread? I have tried following command and it still poped up in a different thread: git send-email --in-reply-to=cag-2hqwummxoqgq5x35ed0mq6um5aus0y8faqry6-iec7ou...@mail.gmail.com mailto:cag-2hqwummxoqgq5x35ed0mq6um5aus0y8faqry6-iec7ou...@mail.gmail.com --identity=systemd patches/0001-build-sys-option-to-disable-tmpfiles.patch FWIW, using Gmane + NNTP + Thunderbird correctly threaded things here for me, so whatever you did, it looks like it works for at least some viewers. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: cleanup agetty command line
'Twas brillig, and Lennart Poettering at 04/06/13 14:41 did gyre and gimble: On Mon, 03.06.13 14:28, Karel Zak (k...@redhat.com) wrote: * baud rate is optional and unnecessary for virtual terminals * term type is optional (default is 'linux' for virtual terminals and 'vt102' for serial lines) * long options are more user-friendly ... all this is supported since util-linux v2.20 (Aug 2011). Applied! Thanks. Aww, pity the util-linux version wasn't corrected first to v2.23 first. Ahh well as long as people remember... :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-shutdown static linking
'Twas brillig, and Ross Lagerwall at 11/06/13 08:19 did gyre and gimble: On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poettering wrote: Hmm, this is certainly weird. normally -.mount should not have any such conflicts. I really wonder where you got those from... What is the contents of /run/systemd/generator/-.mount for you? AFAICT, mount_load_proc_self_mountinfo is called early in the boot process and it calls mount_add_one for each filesystem in /proc/self/mounts, including /. If a unit does not exist already, a new unit is created and the following lines are called (in mount_add_one): r = unit_add_dependency_by_name(u, UNIT_BEFORE, SPECIAL_LOCAL_FS_TARGET, NULL, true); if (r 0) goto fail; r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true); if (r 0) goto fail; While it would be easy to make the conflicts line above conditional on the mount point not being /, I'm not sure how this interacts with mount_load which fills in a whole bunch of stuff and mount_add_default_dependencies which adds a conflict with umount.target so long as the mount point is not /. Without reading the code etc., I'm running systemd with that commit (v204) and I don't get any conflicts for my -.mount unit... So it seems that code is not run for me for whatever reason. After a very quick glance at the code, it could just be that the unit already exists as it's created earlier and thus this bit of the code for -.mount is simply not run? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start/stop messages when activating a target?
[ Please try to avoid top posting and HTML emails if possible!] 'Twas brillig, and Umut Tezduyar at 12/06/13 07:39 did gyre and gimble: On Wed, Jun 12, 2013 at 5:02 AM, Andrey Borzenkov arvidj...@gmail.com mailto:arvidj...@gmail.com wrote: В Wed, 12 Jun 2013 01:32:37 +0200 Michael Olbrich m.olbr...@pengutronix.de mailto:m.olbr...@pengutronix.de пишет: Hi, When booting or during shutdown systemd prints the start stop messages for the services. Is it possible to get those messages when activating a target with systemctl? systemctl already prints status of job unless called with --no-block. Do you want additional status messages on console? Same thing with isolating a target. Job statuses are not printed out on the console and it would be great to see what is being stopped/started at which order for debugging. This was discussed very recently on this list, but I forget the exact message. Lennart thought it would be tricky due to the async nature, but with the standard --no-block behaviour I think this could be achievable (and very useful). See this thread. http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/10880/focus=11081 -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] x-initrd.mount + shutdown umount logic question
Hi, If a mount has the x-initrd.mount option shouldn't it be excluded from the umount loop during shutdown? I've looked at the code but I don't see where they would be excluded. The reason I ask is that a user asked to exclude certain paths from the umount logic, but I didn't like the patch he presented which was very specific and one I'd have to carry downstream (it was used for live ISOs). I'm sure it could be solved in other ways too but one thought was the above option, but while I can see it's use in the fstab generator, I can't see where this info is used in the umounting spree where /usr and / are excluded specifically rather than using the result of the mount_in_initrd() function. Any thoughts? Col For reference: https://bugs.mageia.org/show_bug.cgi?id=8322 -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] x-initrd.mount + shutdown umount logic question
'Twas brillig, and Tom Gundersen at 13/06/13 22:40 did gyre and gimble: On Thu, Jun 13, 2013 at 11:13 PM, Colin Guthrie gm...@colin.guthr.ie wrote: If a mount has the x-initrd.mount option shouldn't it be excluded from the umount loop during shutdown? Makes sense. Also see the patch [PATCH] mount: Don't add conflicts with umount.target for certain mounts just posted by Ross Lagerwall, I guess these could be unified? Yeah, it was actually because I'd read Ross' patch that this mount option was fresh in my mind when reading my bug :) Could possibly be unified but I think Ross' patch stands on it's own anyway. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with SWAP in 204
'Twas brillig, and Henrik /KaarPoSoft at 19/06/13 13:06 did gyre and gimble: However, I do think that you are on to something important here! According to the output of systemctl --full --all --type=swap (attached in previous mail) it seems that systemd is trying to activate swap by every naming scheme (id, uuid, partuuid, partlabel, /dev) without realizing that they symlink to the the same (two) partitions. This did used to be a problem a while back but I thought it had been fixed... perhaps it's regressed in some capacity (or it could just be different but similar symptoms) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Text input on startup (tty-force) disabling after a few seconds
'Twas brillig, and Peeters Simon at 19/06/13 16:51 did gyre and gimble: It might be a bug in the tty-force handling, but this is not a usecase for tty-force, you would be better of using systemd-ask-password I sugest you drop the StandardInput=tty-force from the service file and use this as /etc/mount_truecrypt #!/bin/sh systemd-ask-password Please enter the password to mount your TrueCrypt volumes... | truecrypt -t -k --fs-options=rw,exec,users,async,uid=root,gid=users,umask=077,noatime --mount-options=system --protect-hidden=no /dev/sda1 /media/C /dev/null # that is one line, but gmail will probably break it For more info on this approach see here: http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/ But if Tom is correct (and he usually is) that's probably the simplest route forward. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Socket activation and busname aliases in Network/ModemManager
Hi, Leading on from the Masking socket activated... thread recently, I was thinking a bit about some of the units in Network Manager. Network Manager 0.9.8.0 contains the following NetworkManager.service unit. [Unit] Description=Network Manager After=syslog.target Wants=network.target Before=network.target [Service] Type=dbus BusName=org.freedesktop.NetworkManager ExecStart=/usr/sbin/NetworkManager --no-daemon # Suppress stderr to eliminate duplicated messages in syslog. NM calls openlog() # with LOG_PERROR when run in foreground. But systemd redirects stderr to # syslog by default, which results in logging each message twice. StandardError=null # NM doesn't want systemd to kill its children for it KillMode=process [Install] WantedBy=multi-user.target Alias=dbus-org.freedesktop.NetworkManager.service Also=NetworkManager-wait-online.service This ensures a dbus-org.freedesktop.NetworkManager.service alias. Now the dbus service file /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service has this: # This D-Bus service activation file is only for systemd support since # an auto-activated NetworkManager would be quite surprising for those people # who have NM installed but turned off. Thus the Exec path available to # D-Bus is /bin/false, but systemd knows the real Exec path due to the NM # systemd .service file. [D-BUS Service] Name=org.freedesktop.NetworkManager Exec=/bin/false User=root SystemdService=dbus-org.freedesktop.NetworkManager.service As is uses the dbus alias, I guess the intention is that it only works when the service is enabled in systemd. Without the service being enabled, the alias does not exist and thus it cannot be bus activated. I guess that all makes sense although it is a little bit counter intuitively belt and braces as you cannot enable on-demand bus activation without enabling static activation on boot also (due to WantedBy= line). Now for NetworkManager itself this more or less OK. You'll be needing it pretty much immediately on boot anyway, but what's caught me out a little bit more is that ModemManager (0.7.991) also follows this same pattern. For me this seems a little strange. Modems are not as common these days and I don't really want to have this enabled and running on my machine if I don't really need it. Normally I'd expect it to be bus activated if I go the relevant menu options via one of the NM control applets etc. I presume that to have bus activation by default, the only change needed would be to change the dbus .service file for modem manager to refer to the SystemdService via it's normal name and not via it's bus alias? Is this the expected way to work. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket activation and busname aliases in Network/ModemManager
'Twas brillig, and Colin Guthrie at 20/06/13 09:31 did gyre and gimble: Now for NetworkManager itself this more or less OK. You'll be needing it pretty much immediately on boot anyway, but what's caught me out a little bit more is that ModemManager (0.7.991) also follows this same pattern. For me this seems a little strange. Modems are not as common these days and I don't really want to have this enabled and running on my machine if I don't really need it. Normally I'd expect it to be bus activated if I go the relevant menu options via one of the NM control applets etc. I presume that to have bus activation by default, the only change needed would be to change the dbus .service file for modem manager to refer to the SystemdService via it's normal name and not via it's bus alias? Is this the expected way to work. As Jan Steffens kindly pointed out on IRC, this is already fixed... http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=91898aa8b0bb8164b61e84ae68534c38cebb1482 I'm reassured that my logic was at least correct, but annoyed that I didn't look first before asking the question. Hey ho. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Excessive (virtual) memory usage of journald
'Twas brillig, and Holger Hans Peter Freyther at 21/06/13 16:31 did gyre and gimble: On Fri, Jun 21, 2013 at 04:19:30PM +0200, Kay Sievers wrote: I have no idea why you care what the journald process does with its very own 2+GB of address space, and why it uses 128MB of it. I care about whether or not journald will work reliable on an unattended system. And from what I see there is no limit in the mmap cache. This means that journald can potentially exhaust the virtual address space. Will it happen? I don't know, time will tell. Did you read Lennart's reply? There is a limit to the mmap cache. There are only so many windows that are used (64) and when that limit is reached, the old, less used windows are thrown away and reallocated. I can also assure you that when there was a bug in this cache window code about eight months ago it was quite obvious. This was fixed (http://cgit.freedesktop.org/systemd/systemd/commit/?id=89de694724f376a6852e879fe987e7e531327654) and since that time I've been running several different unattended journals and don't have any issues. 16:40:55 up 45 days, 20:12, 1 user, load average: 0.13, 0.07, 0.10 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 418 0.0 0.2 306028 10284 ?Ss May06 12:34 /usr/lib/systemd/systemd-journald Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LSB Requires-Start: ... $network ... vs network.service
'Twas brillig, and Sage Weil at 03/07/13 04:06 did gyre and gimble: Hi everyone, I have a sysvinit script on fedora 18 (systemd 195) with ### BEGIN INIT INFO # Provides: ceph # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Required-Start:$remote_fs $named $network $time # Required-Stop: $remote_fs $named $network $time # Short-Description: Start Ceph distributed file system daemons at boot time # Description: Enable Ceph distributed file system services. ### END INIT INFO and my daemon keeps failing on startup to bind to it's ip:port. I modified the script to dump systemctl -a output and I see network.service loaded inactive deadLSB: Bring up/down networking NetworkM...online.service loaded inactive deadNetwork Manager Wait Online NetworkManager.serviceloaded active running Network Manager I know next to nothing about systemd (or Fedora, for that matter), but I would expect the $network bit in Required-Start to make the job wait for network.service. Almost, but not quite! Anything prefixed with a $ in LSB headers doesn't refer to a single service, but rather a collection of services all working towareds providing that. Some LSB headers may have Provides: $network for example. In systemd, this concept is generally translated to targets and thus $network actually corresponds to network.target in systemd, not network.service. More info here: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ In your setup (from the output above) it looks like network.service is actually disabled and you're using NetworkManager.service instead to initialise your network. When this happens network.target will be complete pretty much at the same moment that NetworkManager has finished starting. This is because network.target doesn't have any built in knowledge of when a network is considered up (see the link above for several examples of what different people may consider up). In order to actually wait for your network to be up, you need to enable the NetworkManager-wait-online.service. This will then delay the point at which network.target becomes started until after that service exits. This should cause your network dependant service to be started later and you'll be happy! Of course this doesn't help when the network disappears and comes back later, so the *real* solution here is to patch ceph to be aware of the rtnetlink events. It then doesn't have any solid dep on a fairly loosely defined and unreliable point in time when the network is ready and remains available forever more! Hope that helps. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How is GDM supposed to register with systemd-logind? (aka udev 173 causes gnome fallback session)
Hi, I've run into a problem after the latest udev update. Is GDM just supposed to use only PAM config[1] to register with systemd-logind? If so, it's either broken or I've ballsed something up (more than likely!) The problem I'm getting is thus: With udev 172, udev-acl would apply ACLs to devices (such as the DRI device) when console-kit registers a new session. This included the gdm user at the login manager stage. Am I right in saying that now that systemd is taking over the application of ACLs from CK, this means that GDM has to be registered with logind for it to get appropriate ACLs written? If so, this is my problem as gdm does not show up in systemd-loginctl output. With udev 172, both systemd and console-kit would trigger ACL writes, and as gdm is registered with CK, it got it's ACL written via that route. Where as my normal user (which registered with CK and logind) probably got ACLs twice. Now this is where the problem arises. With udev 173, I believe that udev-acl knows whether or not systemd is running and if it is, it it won't write the ACLs. This means that even tho' gdm is still registered with CK, this will never actually trigger an ACL write. This means that gdm does not have access to /dev/dri/card0 and thus cannot determine if the system is capable of 3D accel. This then sets an atom on the root window which the gnome-session-check-accelerated binary looks for. This atom acts as a little cache. If it doesn't exist, it does a full probe and then writes the atom. The next time it runs it finds the atom and skips the actual checks. But as the atom was written by gdm when it couldn't access dri, it says no accel is available, even although the user can actually access it and thus the gnome session is set to fallback mode. I have confirmed that by hacking out the check for the atom in gnome-session-check-accelerated program allows me to login properly into gnome-shell as it performs all the necessary checks every time, ignoring the atom. So, long story short, how is this supposed to work? :) Apologies if this has been covered before, but I couldn't find any reference on the list about it. Thanks Col 1. My gdm pam file looks pretty much identical to the fedora one (at least the one from the package in git) but sans the selinux stuff: #%PAM-1.0 auth requiredpam_env.so auth requiredpam_succeed_if.so user != root quiet auth sufficient pam_succeed_if.so user ingroup nopasswdlogin auth substacksystem-auth auth optionalpam_gnome_keyring.so accountrequiredpam_nologin.so accountinclude system-auth password include system-auth sessionrequiredpam_loginuid.so sessionoptionalpam_console.so sessionoptionalpam_keyinit.so force revoke sessionrequiredpam_namespace.so sessionoptionalpam_gnome_keyring.so auto_start sessioninclude system-auth system-auth contains: #%PAM-1.0 authrequired pam_env.so authsufficientpam_tcb.so shadow nullok prefix=$2a$ count=8 authrequired pam_deny.so account sufficientpam_tcb.so shadow account required pam_deny.so passwordrequired pam_cracklib.so try_first_pass retry=3 minlen=4 dcredit=0 ucredit=0 passwordsufficientpam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8 passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_tcb.so -session optional pam_systemd.so -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How is GDM supposed to register with systemd-logind? (aka udev 173 causes gnome fallback session)
'Twas brillig, and Lennart Poettering at 27/08/11 13:53 did gyre and gimble: On Sat, 27.08.11 13:02, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, I've run into a problem after the latest udev update. Is GDM just supposed to use only PAM config[1] to register with systemd-logind? If so, it's either broken or I've ballsed something up (more than likely!) You need to apply a patch to gdm to make this work: http://pkgs.fedoraproject.org/gitweb/?p=gdm.git;a=commit;h=12886d9c0f01e4f52eea9a3b63602c996bd7f084 https://bugzilla.gnome.org/show_bug.cgi?id=655867 Thanks! I had studied the fedora git stuff, but was looking in the master head rather than the f16 one and thus missed this :( /me wishes master == latest :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
