[arch-general] Protect a cron job from systemd
Hello list, among various tasks, I also run sysstat for monitoring my server's load. The way it runs by default is via the hourly cron, as a job that lasts exactly one hour. Sometimes I need to stop crond (systemctl stop dcron) to perform some short maintainance, and restart it a minute later that I'm done. Previously the sadc monitoring process of sysstat wasn't being killed, since it double forked and stayed up as a daemon. Unfortunately now systemd kills the whole cgroup, and in this manner it's possible to lose up to one hour of accounting logs. Any ideas on how to instruct systemd to not kill it when terminating crond? Thanks in advance, Dimitris
Re: [arch-general] Protect a cron job from systemd
Hi Gaetan, On Wed, 2 Jan 2013, Gaetan Bisson wrote: [2013-01-02 11:07:01 +0200] Dimitrios Apostolou: Any ideas on how to instruct systemd to not kill it when terminating crond? Indeed, cron daemon services should use KillMode=process. I'll implement that for cronie and push it to [testing] right away. If you use another daemon, please create a bug on our tracker. Thanks, that's the solution I was looking for! Filed a bug for dcron (btw I hadn't noticed it moved to community, I thought it is still in core :-), see FS#33273. Dimitris
Re: [arch-general] On /etc/conf.d deprecation
On Sat, 8 Dec 2012, Curtis Shimamoto wrote: On 12/09/12 at 04:01am, Dimitrios Apostolou wrote: Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. Hi Curtis, I can't see how the .include directive would help in the case I mentioned. But even in other cases that it helps, I think it's a much more heavyweight solution to the problem, than the /etc/conf.d EnvironmentFile. What do you think? Dimitris
Re: [arch-general] On /etc/conf.d deprecation
Tom, thank you very much for the extensive reply, I've been searching a lot for the reasoning you explained. On Sun, 9 Dec 2012, Tom Gundersen wrote: Speed is not a concern. The way things should ideally work, IMHO, is: Options related to the init-system, such as where the lock-file is located should be indicated as an option in ExecStart. The reason this makes sense is that it must match what is specifid in PIDFile=. The same goes for any other option that systemd requires to be a certain value to function correctly. All these options are things that the admin would not usually change. Agreed, as I pointed in my example such options should be hardcoded in ExecStart. Unfortunately this comes with the side-effect of missing any updates if ExecStart gets customised in custom unit file (I didn't know about systemd-delta, thanks to everyone who mentioned it). However, options that are unrelated to the init-system should not be specified in ExecStart=, but should be configured in the applications own configuration file. It has nothing to do with systemd, so for systemd to just stupidly read it from one location and pass it on to the program without touching it seems wrong on a conceptual level. More concretely, why we should avoid /etc/conf.d (and why all distros should discourage similar use of their own config directories): * it is distro-specific, so once we switch to unit files provided by upstream, we would have to change the location of the configuration file to whatever is used upstream (maybe the Debain location, or maybe the Fedora one, or maybe something else, it would probably differ from package to package). I think it is better to have a general rule saying we don't use /etc/conf.d with systemd, than package by package moving their config files around as things are upstreamed. Personally I believe all distros that switch to systemd will add their own twist to it. Distro-independant Unit files sounds like Utopia. In reality I expect unit files to be patched for various custom needs of different distros. But anyway if it is actually achieved it would be great. * most packages have their own configuration file where some, if not all, options can be configured. Having two locations for configuring the same options is not ideal, so we want to avoid that to the extent possible. One could imagine using /etc/conf.d for packages where not all command-line options can be configured in the config file. However, what do we then do when one day the config files are extended to deal with all the options? If we drop /etc/conf.d support we'll have the same problems as above: package by package changing behaviour. There are cases when using /etc/conf.d is necessary, but to the extent possible we should try to avoid it. Moreover, the first option should always be to petition upstream to add their own config files with the required options, and only if that is impossible add /etc/conf.d support. Just let me be specific with two examples that I use /etc/conf.d, and it may be more clear why they are still needed: 1) On a memory constrained system I use the following for spamassassin: SPAMD_OPTS=-c --min-spare 0 --max-children 1 -s local5. I don't think this can be customized by other means. 2) For the crond started service of sysstat, I keep all history with HISTORY= in /etc/conf.d/sysstat. I don't know if /etc/conf.d is being deprecated for everything or only for systemd started daemons, but this is a non-systemd example that makes good use of it. Thanks, Dimitris Cheers, Tom
[arch-general] On /etc/conf.d deprecation
Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Thanks in advance, Dimitris
[arch-general] moving custom hooks to systemd
Hello list,
I tried booting with systemd and two custom hooks I have that create the
/var directory on tmpfs didn't work. Google doesn't help here and my
experience with systemd is in its infancy, so is there specific action I
should take?
My custom hooks are set to run during sysinit_postmount and
shutdown_preumount, see attached file for full source.
Thanks in advance,
Dimitris
function varsync_start ()
{
# Assuming that we mounted /var as tmpfs in the previous step
stat_busy Rsyncing /var-sync/ to /var/
/usr/bin/rsync -ax /var-sync/ /var/
stat_done
}
function varsync_stop ()
{
# saving the /var filesystem from the tmpfs
echo -e 'y\ny' | /usr/bin/pacman -Scc /dev/null
stat_busy Rsyncing /var/ to /var-sync/
/usr/bin/rsync -ax --delete /var/ /var-sync/
stat_done
}
add_hook sysinit_postmount varsync_start
add_hook shutdown_preumount varsync_stop
Re: [arch-general] [arch-dev-public] dropping tcp_wrapper support
Hello list, I've been using tcp_wrappers on Linux for more than 10 years, and on Archlinux for 6 years. FWIW I'm not happy about this change. Even though I know that the same functionality is provided by iptables, I consider tcp_wrappers the Unix Way. Anyway there is no value in fighting about personal opinions, and I respect the developers' decision because tcp_wrappers is unmaintained. Hopefully someone will move forward, fork the package and bring it up to date. Dimitris
Re: [arch-general] Change Arch's default crond
On Thu, 21 Apr 2011, Grigorios Bouzakis wrote: Because of these: https://bugs.archlinux.org/index.php?string=dcronproject=1 Mostly https://bugs.archlinux.org/task/18681 The run many times per day bug hasn't bitten me since months ago. And I used to see it really often. Maybe it is fixed? Dimitris
Re: [arch-general] flyspray mailing list
On Sun, 13 Mar 2011, Thomas Bächler wrote: Am 12.03.2011 12:39, schrieb Sergej Pupykin: Hello, what about creating mailing list with all flyspray notifications? I think it can take off some load from bug wrangler person and may be usefull for Arch users. In general, I am not against this. I wouldn't subscribe, but some people might. I have used such lists in other projects without subscribing, the web archives of that list are very useful in showing latest activity. For arch I think it would be good, especially if it showed all the reopening requests and the replys, that are now simply lost. Dimitris
Re: [arch-general] mkinitcpio compression
On Sun, 27 Feb 2011, Thomas Bächler wrote: Am 27.02.2011 03:12, schrieb Dimitrios Apostolou: Hello list, I'm using arch on an old laptop with only 128MB RAM. I had problems compressing the initcpio image with lzma, it always failed allocating memory. The following one-line patch allowed me to set my own compression level in mkinitcpio.conf, with COMPRESSION=lzma -4 Does it also work if you simply omit any option and use the default? If you read the manpage, lzma -9 shouldn't be used anyway. The default setting is -6 and it works, but I prefer -4 to avoid swapping. But what I'm arguing is that the default should be used anyway, and leave it to the user to choose a custom setting only if necessary. FWIW compressing the kernel26-fallback image with various settings (no_options, -e, -4, -4e, -9, -9e) yields almost identical results, even if -9 needs many times the memory of -6. CPU times are all from 20 to 25 seconds: -rw-r--r-- 1 jimis jimis 10293248 Feb 27 15:19 kernel26-fallback.orig -rw-r--r-- 1 jimis jimis 7860781 Feb 27 15:22 kernel26-fallback.4.lzma -rw-r--r-- 1 jimis jimis 7849183 Feb 27 15:25 kernel26-fallback.4e.lzma -rw-r--r-- 1 jimis jimis 7848882 Feb 27 15:26 kernel26-fallback.6e.lzma -rw-r--r-- 1 jimis jimis 7848866 Feb 27 15:28 kernel26-fallback.9e.lzma -rw-r--r-- 1 jimis jimis 7846985 Feb 27 15:22 kernel26-fallback.9.lzma -rw-r--r-- 1 jimis jimis 7846962 Feb 27 15:21 kernel26-fallback.6.lzma Dimitris
[arch-general] mkinitcpio compression
Hello list,
I'm using arch on an old laptop with only 128MB RAM. I had problems
compressing the initcpio image with lzma, it always failed allocating
memory. The following one-line patch allowed me to set my own compression
level in mkinitcpio.conf, with COMPRESSION=lzma -4
--- /sbin/mkinitcpio.orig 2010-10-06 03:23:00.966415649 +0300
+++ /sbin/mkinitcpio2011-02-26 19:11:36.309682053 +0200
@@ -277,7 +277,7 @@
status=0
if [ -n ${GENIMG} ]; then
echo -n :: Generating image '${GENIMG}'...
-if ! /sbin/gen_init_cpio ${FILELIST} | ${COMPRESSION} -9 ${GENIMG};
then
+if ! /sbin/gen_init_cpio ${FILELIST} | ${COMPRESSION} ${GENIMG}; then
echo FAILED
status=1
else
What do you think? Should this make it to the distro? Also I actually
think that *not* forcing -9 compression level, and letting the tool use
its default is a good thing.
Thanks,
Dimitris
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote: The proposed model is based on the web of trust. We would trust on some keys to sign other keys. The main keys would be kept by some high trusty developers. They would sign the public keys of the other developers (and their personal keys too) with the main ones. We, mortal users, would trust the main keys to sign the others, and files signed by the developers' keys would be considered valid, by transitivity of the trust model. So, if a developer's key is compromised, it would be enough to generate another, submit to the key signers and resign the packages affected. In the current workflow, the package building is made in chroots, in the machine of each developer (sound reasons given by Ionut, above). The package would be signed after him testing it. The package would be upload to a staging area and the repo.db would be created. At this point, the repo.db should be signed, but exactly how is the real problem. I have some ideas, as explained in the wiki page, but I don't have the time and my skills are not so wonderful. This is done by Debian and Fedora, at least (those were what I've searched. Others may do it the same way). As far as I know, Fedora uses a different model: a build server and release-wide keys. Search for Fedora koji and Fedora keys for more info. However I don't know how do developers submit RPM spec files to the build server, /maybe/ their own keys are used there. About debian I don't have a clue. Dimitris And one more thing: the implementation is not the main concern. The process is. That's why we muse discuss it thoroughly. A good plan will lead to a good and secure implementation. We should not rush anything. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Tue, 15 Jun 2010, Ionuț Bîru wrote: i found this annoying since, debugging is more harder, i have to download the resulted package to test it, send it, wait for the pool to come. is a mess :D even if my system is compromised, we build our packages in clean chroots. The workflow won't be changing much using a build server: you build and rebuild on your own system using a clean chroot, until you are satisfied with the result. Then you submit PKGBUILD to the build server and forget about it. 99% of the time the build will be successful, since it uses the exact same buildchroot you did, the package will be automatically signed with the arch-wide key stored safely in the server and will be submitted to the repo. 1% of the time something bad happens in the process and you get notified by email... I think the idea of build server is only positive, if we somehow find the equipment needed. :-) Dimitris
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
Hey, what do you think about this way of verifying packages? On Tue, 15 Jun 2010, Dimitrios Apostolou wrote: On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe. Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution? Let me explain it a bit more: Pacman downloads package-1.tar.xz from a random mirror. It then fetches: https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1 Pacman should then know whether the connection to sums.archlinux.org was tampered, since the certificate is signed from a CA in ca-bundle.crt. So if the two hashes match, the package is safe (as safe as the archlinux server...) That way any type of file can be verified (packages, db files, PKGBUILDs, patches etc) provided that its cryptographic hash is in that HTTPS host. Obviously to be able to verify db files, they need a timestamp appended to them, e.g. core-MMDDHHMM.tar.gz. That necessary change is perhaps the most difficult part of this proposal. If too many small files is a problem, maybe the whole db.tar.gz can be served (at the cost of a higher bandwidth utilisation). This solution doesn't use package signing nor a web-of-trust. It simply piggybacks on the tried and true HTTPS mechanism. Primary advantage is the lack of complexity which makes it easy to understand and implement. What do you think? Dimitris
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Wed, 16 Jun 2010, Dan McGee wrote: On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou ji...@gmx.net wrote: Hey, what do you think about this way of verifying packages? On Tue, 15 Jun 2010, Dimitrios Apostolou wrote: On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe. Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution? Let me explain it a bit more: Pacman downloads package-1.tar.xz from a random mirror. It then fetches: https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1 Pacman should then know whether the connection to sums.archlinux.org was tampered, since the certificate is signed from a CA in ca-bundle.crt. So if the two hashes match, the package is safe (as safe as the archlinux server...) That way any type of file can be verified (packages, db files, PKGBUILDs, patches etc) provided that its cryptographic hash is in that HTTPS host. Obviously to be able to verify db files, they need a timestamp appended to them, e.g. core-MMDDHHMM.tar.gz. That necessary change is perhaps the most difficult part of this proposal. If too many small files is a problem, maybe the whole db.tar.gz can be served (at the cost of a higher bandwidth utilisation). This solution doesn't use package signing nor a web-of-trust. It simply piggybacks on the tried and true HTTPS mechanism. Primary advantage is the lack of complexity which makes it easy to understand and implement. What do you think? I think that someone could blow this apart. I break in, touch a package of my choosing without telling anyone, and update the checksum file. Bam- everyone's systems are fucked and the developers never knew because you didn't do anything both cryptographically secure and verifiable, you just added some indirection to the process. HTTPS is both cryptographically correct and verifiable. The case you mention is if someone breaks the one end, that must be guarded most. The danger is there everywhere, on the web-of-trust case someone that broke into a dev's machine and got the key, can sign anything he wants and serve it to the user, who would know? On the distro-wide key case, it's like someone stealing that key, and be able to serve/sign everything. Here, we don't have a key to keep safe, but a server. So it needs special attention about who has access and how hashes are submitted (although HTTPS can secure this process too). But I admit that keeping a server safe is a bit harder than keys, if that was your point. Dimitris -Dan
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote: And keep in mind that package signing per se will not solve this kind of problems. Repository database signing is more important for that solution, but is a problem in the current workflow of Arch developers. How exactly is core and extra database populated? Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target. On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe. Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution? Dimitris
Re: [arch-general] Bad attitude in flyspray again!
Hi, On Fri, 12 Mar 2010, Aaron Griffin wrote: Commenting on closed bugs is not doable in Flyspray. I didn't know it, thanks for the info! So I guess every argument from now on is just for the sake of completion... More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question Once, on another project, I filed a feature request on Flyspray. I also attached some measurements that showed how slow was the current way of doing things. After some monts the feature got implemented and the bug closed. I liked the feature, the program was much faster, and I wanted to attach measurements from the same machine that showed the difference. I didn't because I felt a reopen request would bother the developers. But even for true reopen requests, IMHO the request itself should be logged as a comment so that others can see it, and why it was rejected. Dimitris
Re: [arch-general] Bad attitude in flyspray again!
On Fri, 12 Mar 2010, Dan McGee wrote: On Fri, Mar 12, 2010 at 2:59 PM, Damjan Georgievski gdam...@gmail.com wrote: Commenting on closed bugs is not doable in Flyspray. Actually it is doable, it's a configuration option per project. Check http://bugs.archlinux.org/pm/proj1/prefs More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers assuming malicious users up-front? - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question I see at least several good uses of allowing comments on closed bugs, sometimes even adding aditional reasons why the bug needs to *stay closed*. Thanks. I just turned this on for the pacman bug tracker because I do find comments after closing a feature that is a net positive (with some trolling drawbacks, of course). Me thanks! I think it will generally be positive. And in any case you can turn it back off if it's abused. Dimitris -Dan
Re: [arch-general] Bad attitude in flyspray again!
My primary complaint against flyspray is that it doesn't allow comments to be added after the bug is closed. The only way is by doing a request to reopen the bug, and even in that case your comment is not added to the comment list. Wouldn't this functionality remedy the closing bugs early situation? Is it supported in flyspray? Dimitris
Re: [arch-general] pacman overwriting files (was Re: dcron 4.2)
On Wed, 10 Feb 2010, Thomas Bächler wrote:
Am 10.02.2010 21:30, schrieb Dimitrios Apostolou:
Guys that thing bit me again: During the big libpng upgrade
initscripts package got upgraded too and /etc/rc.{sysinit,shutdown}
got overwritten without notifying me. Because of special changes I've
made to mount /var as tmpfs, and because I forgot to put the files in
the NoUpgrade line of pacman.conf, the system was unbootable and after
fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit
USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I
can't thing of anything negative for such a feature.
This will definitely not happen. pacman will only notify you on files
that are marked as backup in the package and thus listed in pacman
-Qii! All other will be overwritten without a warning (pacman doesn't
know you modified them). rc.{sysinit,shutdown} are not supposed to be
Thanks for the info, so it's not a matter of policy but I now see it's
technically not feasible... I wish this was mentioned before. I now
noticed that pacman stores the checksums of files in the %PACMAN% array
inside files file. I somehow was under the impression that no checksums
were needed, only the timestams inside the installation tarball.
modified by the user - if you still want to do that, the NoUpgrade
feature of pacman will do the job, but then you are completely on your
own (Arch gives you all freedom you want, as long as you know you and
only you are to blame for problems)!
You should try to make your changes work inside Arch:
1) If your changes are general enough to make it into the mainstream
initscripts as a feature (or an optional one), submit a feature request
with a patch against latest git.
2) If your changes are for local usage only, try to integrate them with
the new initscripts hooks system. You can also request to add more hooks
to be added in initscripts, just open a feature request. The hooks
system is explained in the comments in /etc/rc.d/functions.
My patch is only 3 lines before any other initialisation has taken place,
and copies /var from disk to tmpfs. I'm using it on my Eee 901 for over
one year, but it's really custom and non-portable. I didn't know about the
new hooks system, I think I like it. When I find some time to port my
3-lines patch to it, I'll post it here in case someone else needs it.
Dimitris
[arch-general] pacman overwriting files (was Re: dcron 4.2)
On Tue, 12 Jan 2010, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler tho...@archlinux.org wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is
goint to be overwritten or not, *before* it actually happens? And even
if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's
been some time) I had completely lost my changes, and I had to rewrite
them.
pacman -Qii is your friend.
This.
pacman -Qii dcron will show you all the backup files that pacman will
take care of.
Guys that thing bit me again: During the big libpng upgrade initscripts
package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten
without notifying me. Because of special changes I've made to mount /var
as tmpfs, and because I forgot to put the files in the NoUpgrade line of
pacman.conf, the system was unbootable and after fixing it pacman wants to
download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like:
WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I
can't thing of anything negative for such a feature.
Dimitris
Re: [arch-general] pacman overwriting files (was Re: dcron 4.2)
On Wed, 10 Feb 2010, dave reisner wrote:
On Wed, Feb 10, 2010 at 3:30 PM, Dimitrios Apostolou ji...@gmx.net wrote:
Guys that thing bit me again: During the big libpng upgrade initscripts
package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten
without notifying me. Because of special changes I've made to mount /var as
tmpfs, and because I forgot to put the files in the NoUpgrade line of
pacman.conf, the system was unbootable and after fixing it pacman wants to
download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit
USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I
can't thing of anything negative for such a feature.
Dimitris
Or simply add rc.sysinit to the backup array in the PKGBUILD. I was bit by
this as well, but I had a backup close by. Imagine that.
Because of my experience in this area... I also had a backup and that's
how I fixed my system. BU* that happened after I realised something got
overwritten, that is *after* the reboot, which costed me my pacman db.
Can you imagine it? ;-)
Dimitris
d
Re: [arch-general] pacman overwriting files (was Re: dcron 4.2)
On Wed, 10 Feb 2010, Aaron Griffin wrote:
On Wed, Feb 10, 2010 at 2:30 PM, Dimitrios Apostolou ji...@gmx.net wrote:
On Tue, 12 Jan 2010, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler tho...@archlinux.org
wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is
goint to be overwritten or not, *before* it actually happens? And even
if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's
been some time) I had completely lost my changes, and I had to rewrite
them.
pacman -Qii is your friend.
This.
pacman -Qii dcron will show you all the backup files that pacman will
take care of.
Guys that thing bit me again: During the big libpng upgrade initscripts
package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten
without notifying me. Because of special changes I've made to mount /var as
tmpfs, and because I forgot to put the files in the NoUpgrade line of
pacman.conf, the system was unbootable and after fixing it pacman wants to
download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER
CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I
can't thing of anything negative for such a feature.
I can: extra work for people who are already taxed. You want it? Submit a patch.
OK I like that, from previous answers I thought it was a choice not to fix
it. I will try to submit the patch.
Dimitris
Re: [arch-general] 2 Killer kde4 dark themes - DR you listening??
Hi, sorry for hijacking your thread but speaking of dark themes, I have been looking for ages for a nice reverse theme for gtk+ but every single one I remember wasn't perfect... Anyone 100% happy with a reverse theme? And most importantly, how the /heck/ do you handle the *bright* *white* pages of the web... I'd tried creating a custom CSS for me, but it broke too many pages... Thanks, Dimitris
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon, 11 Jan 2010, Aaron Griffin wrote: If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them. Thanks, Dimitris
Re: [arch-general] CUPS
My guess is you need to authenticate to the Active Directory domain of your network. Windows does it automatically when you login. I have seen this case in the past but I can't help you with the specifics. You can google for something like cups samba active directory authentication... Dimitris
Re: [arch-general] high CPU temperature with 2.6.32
On Wed, 6 Jan 2010, Marti Raudsepp wrote: On Mon, Jan 4, 2010 at 11:07 PM, Dimitrios Apostolou ji...@gmx.net wrote: Using powertop I can see more than 100K wakeups/s (extra_timer_interrupt is first on the list but I think it's irrelevant since it only shows about 100 wakeups), and the CPU is not going into C2 mode at all. Strangely however the cpu is 99% idle, and top doesn't show system or user cpu usage. This sounds bad. Let me get this straight. Wakeups-from-idle per second shows 100 000, but no large numbers show up under Top causes for wakeups? Can you post the contents of your /proc/interrupts and /proc/timer_stats twice, taken within a few seconds difference? cat /proc/timer_stats /proc/interrupts echo echo sleep 2 cat \ /proc/timer_stats /proc/interrupts Timer Stats Version: v0.2 Sample period: 0.000 s 0 total events CPU0 0: 79154XT-PIC-XTtimer 1: 1621XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 3: 2XT-PIC-XT 4: 3XT-PIC-XT 5: 6XT-PIC-XTau8810 6: 5XT-PIC-XTfloppy 7: 0XT-PIC-XTparport0 8: 4XT-PIC-XTrtc0 9: 4XT-PIC-XTacpi 10: 2XT-PIC-XT 11: 45870XT-PIC-XTyenta, yenta, uhci_hcd:usb1 12: 82960XT-PIC-XTi8042 14: 15309XT-PIC-XTata_piix 15: 0XT-PIC-XTata_piix NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts PND: 0 Performance pending work RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts MCE: 0 Machine check exceptions MCP: 4 Machine check polls ERR: 0 MIS: 0 Timer Stats Version: v0.2 Sample period: 0.000 s 0 total events CPU0 0: 79271XT-PIC-XTtimer 1: 1622XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 3: 2XT-PIC-XT 4: 3XT-PIC-XT 5: 6XT-PIC-XTau8810 6: 5XT-PIC-XTfloppy 7: 0XT-PIC-XTparport0 8: 4XT-PIC-XTrtc0 9: 4XT-PIC-XTacpi 10: 2XT-PIC-XT 11: 45914XT-PIC-XTyenta, yenta, uhci_hcd:usb1 12: 82960XT-PIC-XTi8042 14: 15330XT-PIC-XTata_piix 15: 0XT-PIC-XTata_piix NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts PND: 0 Performance pending work RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts MCE: 0 Machine check exceptions MCP: 4 Machine check polls ERR: 0 MIS: 0 I have already compiled a minimal 2.6.31 and a 2.6.32 kernel and the problem seems to be a regression introduced in the former. So I'm trying to find time for a git bisection... Any other ideas? Dimitris Marti
Re: [arch-general] high CPU temperature with 2.6.32
On Wed, 6 Jan 2010, Marti Raudsepp wrote: On Wed, Jan 6, 2010 at 3:23 PM, Dimitrios Apostolou ji...@gmx.net wrote: Timer Stats Version: v0.2 Sample period: 0.000 s 0 total events Huh? Something's broken with your /proc/timer_stats. Either that, or some application is polling the file at an insane rate. Were you running powertop in the background at this time? No I wasn't running anything in the background, really stange indeed... Nothing suspicious in your /proc/interrupts -- I assume the 'processor' module was still loaded at the time you took these samples? right I have already compiled a minimal 2.6.31 and a 2.6.32 kernel and the problem seems to be a regression introduced in the former. So I'm trying to find time for a git bisection... Any other ideas? You can contact people responsible for the 'processor' module. Linux get_maintainer.pl lists these emails for drivers/acpi/processor_core.c: Len Brown l...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com Andrew Morton a...@linux-foundation.org Yinghai Lu ying...@kernel.org Alex Chiang achi...@hp.com linux-a...@vger.kernel.org linux-ker...@vger.kernel.org (Yeah, feel free to send an email to all recipients, that's how people usually communicate on LKML) Thanks for the tips, they are very useful! Dimitris Marti
Re: [arch-general] high CPU temperature with 2.6.32
On Mon, 4 Jan 2010, Dimitrios Apostolou wrote: Hello, pacman just brought kernel 2.6.32 for my old laptop (P3 500MHz). A strange thing I noticed is that the fan won't go off when CPU is idling like it used to. Using powertop I can see more than 100K wakeups/s (extra_timer_interrupt is first on the list but I think it's irrelevant since it only shows about 100 wakeups), and the CPU is not going into C2 mode at all. Strangely however the cpu is 99% idle, and top doesn't show system or user cpu usage. FYI this happens when the module processor is inserted, whence I get something like marking tsc as unstable due to halts in idle. Using acpi_pm clocksource. Before that the CPU is idling cool, but from then on I get ~130K wakeups/s and the CPU runs hot. My workaround for the moment is booting with parameter clocksource=pit. Anyone else seeing such behaviour? Thanks in advance, Dimitris
Re: [arch-general] high CPU temperature with 2.6.32
On Tue, 5 Jan 2010, Sven-Hendrik Haase wrote: Do you run acpi-cpufreq? No I don't. In fact I don't think the CPU is able to lower its frequency. Dimitris
Re: [arch-general] wchan info in ps
On Sat, 14 Nov 2009, Xavier wrote: On Sat, Nov 14, 2009 at 7:12 PM, Dimitrios Apostolou ji...@gmx.net wrote: Hello list, is anyone actually getting WCHAN information from either ps or top? To try it just use ps opid,wchan,cmd. I only get dashes, any idea why? man ps wchan WCHANname of the kernel function in which the process is sleeping, a - if the process is running, or a * if the process is multi-threaded and ps is not displaying threads. That said, I only get a dash for the ps itself, and sometimes also for the shell. PID WCHAN CMD 4040 n_tty_ -zsh 4620 rt_sig zsh 4626 poll_s irssi 12880 pause screen -r 12942 rt_sig /bin/zsh 14936 rt_sig /bin/zsh 14939 poll_s cmus 23759 poll_s vim lib/libalpm/dload.c 23770 rt_sig /bin/zsh 23842 - ps opid,wchan,cmd I still can't figure this one out. The output you get is the correct one (I get that on Redhat systems) however how did you manage to get it on arch??? I tried on two more PCs with archlinux, but I still get dashes! So I see the same bogus behavior on 3 different systems (all 32-bit), I guess it's not my fault. Ideas? Dimitris
[arch-general] wchan info in ps
Hello list, is anyone actually getting WCHAN information from either ps or top? To try it just use ps opid,wchan,cmd. I only get dashes, any idea why? Thanks, Dimitris
Re: [arch-general] wchan info in ps
On Sat, 14 Nov 2009, Xavier wrote: On Sat, Nov 14, 2009 at 7:12 PM, Dimitrios Apostolou ji...@gmx.net wrote: Hello list, is anyone actually getting WCHAN information from either ps or top? To try it just use ps opid,wchan,cmd. I only get dashes, any idea why? man ps wchan WCHANname of the kernel function in which the process is sleeping, a - if the process is running, or a * if the process is multi-threaded and ps is not displaying threads. That said, I only get a dash for the ps itself, and sometimes also for the shell. PID WCHAN CMD 4040 n_tty_ -zsh 4620 rt_sig zsh 4626 poll_s irssi 12880 pause screen -r 12942 rt_sig /bin/zsh 14936 rt_sig /bin/zsh 14939 poll_s cmus 23759 poll_s vim lib/libalpm/dload.c 23770 rt_sig /bin/zsh 23842 - ps opid,wchan,cmd I get all dashes, so I must have broken something on my setup... :-( You are on 32-bit, right? Dimitris
Re: [arch-general] archlinux on old hardware
On Thu, 17 Sep 2009, Nicolas Bigaouette wrote: I'm using Arch on a old Sony Vaio: pentium II 200MHz with ~64MB of ram. It Cool, especially since you have desktop software on it... How did you manage to install with only 64MB RAM? is running LXDE. It is slow to boot, but I suspend without problems (its up since a couple of month with suspend+resume each morning). It is running slow, but this machine is now my alarm clock, and it works perfectly streaming mp3 over wireless internet. I think I have opera on it, but don't ask too much for web surfing... Else, Arch is great! ;) Dimitris
Re: [arch-general] archlinux on old hardware
On Thu, 17 Sep 2009, Daenyth Blank wrote: On Thu, Sep 17, 2009 at 17:04, Dimitrios Apostolou ji...@gmx.net wrote: The other is that I had trouble finding a truly lightweight X terminal (there were times when xterm was considered bloated ;) so I packaged myself rxvt. Most other distributions offer it so in case you decide to include it I attach the PKGBUILD. rxvt is available in the AUR (which you can read about on the wiki). The repos have mrxvt and rxvt-unicode packaged as binaries. Thanks for the tip, I didn't search the AUR. I assumed it was deprecated because of rxvt-unicode, which is much more heavyweight. Would the devs consider including it in extra? it's one of the simplest but most basic packages available. Dimitris
Re: [arch-general] archlinux on old hardware
On Fri, 18 Sep 2009, Nicolas Bigaouette wrote: 2009/9/18 Dimitrios Apostolou ji...@gmx.net On Thu, 17 Sep 2009, Nicolas Bigaouette wrote: I'm using Arch on a old Sony Vaio: pentium II 200MHz with ~64MB of ram. It Cool, especially since you have desktop software on it... How did you manage to install with only 64MB RAM? Note that I'm not sure how much RAM I have. I might have more, like 80MB, but not much more. I can verify tonight. I remember trying to access the web with it (with arora I think), it was possible but really slow, and forget about tabs. Just FYI you might want to try the following tips to speed things up, they work in my case: * forget about XDM/GDM/KDM and use startx, or a direct autologin from /etc/inittab! * Don't run LXDE, GTK+ 2.x is way too heavy for such hardware. My choice for window manager is JWM, recompiled with minimal dependencies, together with a script to auto-generate the menu from *.desktop files (I can post this if you need it). * Try my PKGBUILD for rxvt, today even xterm has antialiased fonts which is too much for this old hardware * Command line mail client (alpine is my personal choice) * Dillo 2 or links-g (started with links -g) for web browser. Unfortunately that's not enough to provide the full web2 experience so when I'm open to alternatives you may suggest ;-) As for installation, it was a pain. Mainly because this laptop does not have a cd drive, and does not support booting from USB... When I got that machine, debian was on it with grub. So I copied the usb thumb drive image's kernel to the hd, added an entry for this kernel in grub, and booted the fs on the usb drive. Started installation, wiped-out debian and only have arch now. Put back arch's grub and its configuration, and that's it... ;) awesome way to install :-) Dimitris P.S. Oh, did I mention sysctl vm.swappiness=0?
[arch-general] archlinux on old hardware
Hello list,
I just installed archlinux on a very old laptop of mine PIII at 500MHz
with 128MB RAM. I am planning on using it as a desktop... I should mention
two facts.
First is that I installed from CD succesfully without problems. I remember
in the past the installer would fail with such amount of ram but it seems
today's squashfs goodness is paying back... So what are the current
minimum requirements?
The other is that I had trouble finding a truly lightweight X terminal
(there were times when xterm was considered bloated ;) so I packaged
myself rxvt. Most other distributions offer it so in case you decide to
include it I attach the PKGBUILD.
I'm wondering, what's the oldest equipment you run archlinux on? Is it for
desktop or server usage?
Thanks,
Dimitris
pkgname=rxvt
pkgver=2.7.10
pkgrel=1
pkgdesc=a really lightweight terminal for X
options=(!libtool)
arch=(i686 x86_64)
depends=('libx11')
makedepends=()
optdepends=()
url=http://rxvt.sourceforge.net;
license=(GPL)
source=(http://downloads.sourceforge.net/rxvt/${pkgname}-${pkgver}.tar.gz)
md5sums=('302c5c455e64047b02d1ef19ff749141')
build() {
cd ${startdir}/src/${pkgname}-${pkgver}
./configure --prefix=/usr \
--mandir=/usr/share/man \
--disable-everything \
--enable-shared \
--enable-rxvt-scroll
make || return 1
mkdir -p ${startdir}/pkg/usr/share/terminfo
export TERMINFO=${startdir}/pkg/usr/share/terminfo
make DESTDIR=${startdir}/pkg install
}
Re: [arch-general] poll: udev uevents settle wait time
On Thu, 2008-05-29 at 06:12 +0200, Karolina Lindqvist wrote: måndagen den 19 maj 2008 skrev Dimitrios Apostolou: Let me start with a P3 800MHz I have running arch. Normal wait time: ~11.5s acpi=off wait time: ~5s What about yours? Toshiba laptop, pentium 233MHz, wait time 85564ms :-O Fantastic! It's probably the slowest arch machine I 've seen... How much RAM does it have? How did you perform the installation? Are you using any desktop environment, if so how does it perform? Thanks, Dimitris
Re: [arch-general] Any way to decrypt hashes set by ssh HashKnownHosts?
Hi, Was this change forwarded to the OpenSSH developers? I am sure that if it is indeed better security-wise to hash the known_hosts file, they would change the default configuration upstream. I'm also sure that they would give very good reasons for not wanting to do so. Thanks, Dimitris
Re: [arch-general] About Arch pkg compress format
Hi, On Tue, 2008-05-20 at 10:14 +0200, Jan de Groot wrote: Pacman itself is ready for .tar.bz2 package files. The whole issue with .bz2 files is that compression and decompression times increase a lot without giving the same amount of size reduction back. We've done some recent tests with LZMA, which compresses just as good as bzip2 at the lowest compression rate, but does it at the same speed as gzip. About LZMA I should add that when using higher (actually the default) compression rate, compression is much better than bzip2 but takes more time/memory. Decompression however, which is what really matters in a packaging format, is kept fast and lightweight. The downside is that LZMA is not supported by libarchive, and won't be supported officially either, because libarchive is BSD licensed and LZMA is GPL licensed. Can't this problem be circumvented by spawning the lzma command line utility, and piping all data to it? I understand that this perhaps negates the purpose of libarchive, but the overhead should be small. Thanks, Dimitris
Re: [arch-general] About Arch pkg compress format
On Wed, 2008-05-21 at 19:39 +0200, Jan de Groot wrote: What's the memory usage when unzipping an LZMA file? Is it much higher than the needs of gzip? We already have problems supporting low-memory systems with our installer, adding a compression algorithm that eats more memory will cause even more problems for these systems. Yes it eats more memory in comparison to gzip, at least when high compression is chosen. But still the memory it uses is not much. From the official site of the LZMA utils: http://tukaani.org/lzma/benchmarks RAM usage on decompression gzipbzip2 lzmash lzmash -e 1 1 MB 1 MB 1 MB- 2 1 MB 2 MB 2 MB- 3 1 MB 2 MB 1 MB1 MB 4 1 MB 2 MB 2 MB2 MB 5 1 MB 3 MB 3 MB3 MB 6 1 MB 3 MB 5 MB5 MB 7 1 MB 3 MB 9 MB9 MB 8 1 MB 4 MB17 MB 17 MB 9 1 MB 4 MB33 MB 33 MB The memory usage of lzma stays competitive with bzip2 when files have been compressed with lzmash -6 or with a smaller option. The files compressed with the default lzmash -7 can still be decompressed, even on machines with only 16 MB of RAM, but sometimes you don't have even that much memory available. If you compress with lzmash -8 or lzmash -9, you should think if the users need to be able to decompress your files also on ancient computers. I fully understand the license problem and personally I am pretty happy with the gzip algorithm, I am just pointing facts so that a technically correct conclusion is reached. Dimitris
[arch-general] poll: udev uevents settle wait time
Hello list, I have recently seen the new feature of the initscripts, where the waiting time for uevents settling is being reported. So since we are all interested in booting speed, what are the times being reported for your computer? Let me start with a P3 800MHz I have running arch. Normal wait time: ~11.5s acpi=off wait time: ~5s What about yours? Dimitris
Re: [arch-general] pacman changes libcrypt.so.1 symlink
On Thursday 08 May 2008 13:10:02 Lukáš Jirkovský wrote: Yeah, but it glibc compiling much processor time. I've made small shell wrapper for ldconfig and it works. Maybe the best solution would be adding blowfish support to glibc's libcrypt itself. Yet another external patch for glibc? Baaah However you may find interesting that glibc already supports sha256/sha512 password hashes. I remember having read that they intentionally prefered implementing those instead of blowfish. Ok I found it: http://people.redhat.com/drepper/sha-crypt.html Dimitris
Re: [arch-general] [arch-dev-public] policy on desktop files?
On Thursday 08 May 2008 15:58:51 bardo wrote: On Thu, May 8, 2008 at 2:29 PM, Grigorios Bouzakis [EMAIL PROTECTED] wrote: Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to the packages. Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it. At the moment I don't. When I announced the project it got a good reaction, so I carried on with it, but after a while creating and providing desktop files through the bug tracker I started receiving the upstream problem answer. This has become pretty frequent, so lately I haven't been doing very much on the Arch side. The few developers I tried to contact didn't do anything, so I suppose there's little to no interest from them. The whole thing has started to become more frustrating than anything, so at the moment I'm not working on it anymore. IMHO, even though I'm aggresively against patching, I don't consider the .desktop files as patches. They are some extra, *non-code* files, that is fair for the distro to provide (like other configuration files). I don't really blame the app developers that don't include them upstream. Dimitris Corrado
[arch-general] root CA certificates bundle
Hello list, In the past I had set-up some software I use (mpop) to read the root CAs certificates from /usr/share/curl/curl-ca-bundle.crt but it seems that some update broke that. I could easily find an alternative, since many archlinux packages come with their own CA cert bundle but it reminded me I wanted to post about it... I think it would be better if archlinux had its own CA-certificate-bundle package, and all appropriate packages used that one. As a start we could use the file provided by curl or firefox, wrap it in its own package, and force its installation in every system. Of course this raises important issues concerning security, like how to distribute such a package since plain HTTP downloads (and without any signature verification) that pacman uses are insecure. The problem surely existed before, it's just that creating such a package mandates a solution. Nobody wants to have forged CA root certificates... Undoubtedly the safest is to include it once in the install CDs and never update it through the web, it seems pretty impossible though. So what do you think? Thanks, Dimitris
Re: [arch-general] kernel26 2.6.25-1 enters [testing]
Dream Team wrote: Le Sunday 20 April 2008 15:23:38 Erwin Van de Velde, vous avez écrit : On Saturday 19 April 2008, Thomas Bächler wrote: - Removed mactel patch The removal of these patches was because a) there are no new patches available for 2.6.25 and b) I am trying to reduce the amount of patching, especially if it only benefits a few people or can be potentially dangerous. As far as I know, the mactel patch is required for some hardware support on intel-based mac systems and contains important fixes. This does not seem like one patch too many, but an essential one for all users who, like me, have mac hardware. I do understand your wish to reduce the number of patches, but throwing out patches required for support of important hardware does not seem the way to go to me. Regards, Erwin I also am using arch on my mac, and I find this essential and should not be removed if you find 2.6.25 compatible patchs (I am sure that they will come out in not so many time) Arnaud Hi, I would suggest to test the new kernel on your mac before complaining, perhaps it supports it better now. And if after that much time this patch is necessary for such common hardware and hasn't been imported upstream, I think you should contact the LKML. Dimitris
Re: [arch-general] signoff kernel26-2.6.24.3-6
Just my humble opinion on some of the issues raised: What Arch needs is to have strict guidelines on PKGBUILDs and kick out any developers that don't have the same idea. A proposition: * Patches are unacceptable unless in the case the software wouldn't work *at all* (Hint, qt PKGBUILD) +1 PLEASE no more patches that just add functionality! I want VANILLA packages and that's one reason I chose Arch. The users should complain to the specific application's developers for missing functionality and bugs. If arch returns to the arch way please remind me to post a list of packages with superfluous patches applied... * Bugs and other issues that come from upstream, _should be fixed upstream_. If people do have problems with a certain issue, they can abs and makepkg themselves. (See rule 1) +1 Another point of interest may be that many people used to find gnome coming ugly by default (I don't know if this still the case). So what? Selecting your own theme is just a few mouse clicks away. Arch should never come with a fscked up KDE or Gnome profile like Ubuntu and others do. In fact, packages should *always* come with the defaults shipped by upstream. +1 Again I like respecting the application's developers choices. Dimitris
