On Tuesday 16 February 2010 06:49:33 Karl Eichwalder wrote:

Am Fri 12 Feb 2010 10:21:22 AM CET schrieb Michal Seben <mseben@suse.cz>:

...

Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong.

As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3]

I'd appreeciate if you'd take the pain to create a feature and set the "docimpact" flag. In case cronie is fully backwards compatible, please state it there -- this could save us quite some time...

https://features.opensuse.org/309015

[BTW, I hate footnotes in mails... ;) It is neither reader friendly nor compatible with traditional quoting.]

...

[1]https://fedorahosted.org/cronie/ [2]https://build.opensuse.org/package/show?package=cronie&project=Base%3A System [3]http://en.opensuse.org/Cron_replace#Differences_between_old_openSUSE.2 7s_cron_and_new_openSUSE.27s_cronie

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 16/02/10 18:41, Patrick Shanahan wrote:

I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null

What kind of problems ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wednesday 17 February 2010 01:32:25 Patrick Shanahan wrote:

* Cristian Rodríguez <crrodriguez@opensuse.org> [02-16-10 17:57]:

...

On 16/02/10 18:41, Patrick Shanahan wrote:

...

I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null

What kind of problems ?

The next instance cannot run because the previous has not cleared/ended. And the only thing I had done was install cronie. Reinstalling cron corrected the problem.

But it requires "rpm -e cronie" before reinstalling cron.

I can go thru it again and make checks/tests, if you wish and describe what you want.

thanks Patrick ! I file a bug report : bnc#580438 and i will check what's going on thanks again ! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Patrick Shanahan <ptilopteri@gmail.com> [02-17-10 20:45]:

further info:

reinstalled cronie

received duplicate cron error emails that mairix failed for existing lock.file

but mairix_database *was* updated

Apparently cronie is starting *three* instances of: */10 * * * * /usr/bin/mairix -p > /dev/null

The first is successful and the other two fail

rpm -e --nodeps cronie reinstalled cron

This information was added to the bug_report bnc#580438

I closed the bug, WORKS FOR ME. Investigation revealed that the install somehow provided multiple processes of cron active. Whether I did it or the install script, I don't know. Killing the extra processes resolved the problem and cronie has performed properly for the last eight hours. Will advise if further problems. tks, -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Sun, Jun 05, 2011 at 04:12:11AM +0200, Carlos E. R. wrote:

I found a mis-feature of cronie:

If a user has a crontab entry that starts with a dash (meaning: don't log) the entire line is skipped. Existing crontab entries like that fail silently.

If a user tries to create a crontab with a line like that, he gets an error:

File /tmp/crontab.hA3Nld saved crontab: installing new crontab "/tmp/crontab.hA3Nld":5: bad option errors in crontab file, can't install.

that doesn't explain anything. However, there is an entry in the syslog that does:

... crontab 4032 - - (CRON) ERROR (Only privileged user can disable logging)

This is hardcoded, it is not possible to disable; see:

https://fedorahosted.org/cronie/browser/src/entry.c, *load_entry().

The possible workaround is to add a file to /etc/cron.d/, where entries have a syntax that specifies under which user the entry runs, and allows the dash.

That's because it is a system crontab. Disabling logging is permitted only for system crontabs and for the user with uid 0 (root). The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed." But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron). As I see it, The current cronie behaviour is correct. Well, the manual page should mention the logging disabling ability as the old manual did. -- Vita Cizek

Carlos E. R. wrote:

On 2011-06-06 10:15, Vitezslav Cizek wrote:

...

But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).

Didn't know it was a bug, as I found it useful.

...

As I see it, The current cronie behaviour is correct. Well, the manual page should mention the logging disabling ability as the old manual did.

It would be better if the feature could be disabled for certain users, with a list, such as the one allowed users.

Linux machines are not always big multiuser installations, but also home, personal systems. No reason why a plain user should not be able to disable logging, if the root (same person) so wishes.

Sounds like a feature request? (as it's not a current cronie functionality). -- Per Jessen, Zürich (18.8°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Jun 06, 2011 at 04:36:58PM +0200, Stefan Seyfried wrote:

Am Mon, 6 Jun 2011 10:15:39 +0200 schrieb Vitezslav Cizek <vcizek@suse.cz>:

...

The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."

But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).

As I see it, The current cronie behaviour is correct.

Well. I would argue that "correct" in this case would be to not disable logging, but to still execute the command. Principle of least surprise. Maybe additionally log a warning that this is going to no longer work in after dec 31 2020 or something like that.

I meant "correct" as "cron was intended to behave like that". Submitted a fixed cron package: crontab.5 now includes: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed." Also, when an unprivileged user uses the dash, cron complains about incorrect minute, instead of an invalid option.

Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".

You're right. But as this behaviour was caused by a bug, I think it should be fixed. -- Vita Cizek

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-06 18:20, doiggl@velocitynet.com.au wrote:

Hello I get broken factory links on factory [1]

Please don't hijack threads. Create your own. We are talking here about cronie, not links. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3tS7kACgkQtTMYHG2NR9XkxACgiU3mp4WsAQgo8verFH2QtMrc cgkAnA1TFiNtXHOIwi1VD4AAnANkpAjl =WLCb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-06 17:02, Vitezslav Cizek wrote:

On Mon, Jun 06, 2011 at 04:36:58PM +0200, Stefan Seyfried wrote:

...

Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".

You're right. But as this behaviour was caused by a bug, I think it should be fixed.

Yes, it should be fixed that cronie fails silently when it finds an entry with a dash. It should complain in the log and/or the email that the plain users can not use the dash; and ignore the dash and execute the entry, and log it. The current behavior of silently ignoring the entry is a bug. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3tTUwACgkQtTMYHG2NR9V2bwCfZDZPGCfukTkVaw+EGMTO8cTi 7PUAn1dy9+PDErQgMTdQ6+68Jg4GqFfK =uQEm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-07 14:11, Vitezslav Cizek wrote:

On Mon, Jun 06, 2011 at 11:57:32PM +0200, Carlos E. R. wrote:

...

Yes, it should be fixed that cronie fails silently when it finds an entry with a dash. It should complain in the log and/or the email that the plain users can not use the dash; and ignore the dash and execute the entry, and log it.

It doesn't fail silently, it complains to syslog with: "(CRON) ERROR (Only privileged user can disable logging)"

It fails silently. The syslog entry existed already, machine was using cron. Then machine is upgraded to oS 11.4, cron changed to cronie (not my decision), entry is no longer valid, it is not executed, nothing in syslog. Silence. It complains to syslog when the user edits the entry; but then remember that a plain user is not authorized to see what is in syslog (-rw-r----- root root), so to all purposes the failure is also silent.

I prefer Stefan's approach, cron will strip leading dashes from unprivileged users' crontabs during an update.

Too late. 11.4 was released.

The only case when a dash can slip to a user's crontab remains, when someone copies a crontab between different systems, but this is the user's fault and he should handle it himself.

You forget supported scenario of openSUSE upgrade. Not the user fault, but the packager fault. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3uKh4ACgkQtTMYHG2NR9Xx0wCgj9slsLk0Vdw/sdZGfRaD/+k0 HU0AnA85wfXL9m2AB+LZ9dS5MkPHSoUC =gIYP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-07 14:20, Jeff Mahoney wrote:

Agreed. This is really the only approach that would make cronie an acceptable replacement.

But 11.4 was released with a faulty cronie. That is how I found out. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3uLBEACgkQtTMYHG2NR9VlZwCfTjS5sAn8Wqs06dlLhTD7nCwa ZOsAnRqkZrmFLjPDEMamZHASdMs/BhV4 =SDT4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

I filed two separate bugs for this issue: On Mon, Jun 06, 2011 at 10:15:39AM +0200, Vitezslav Cizek wrote:

Hi,

On Sun, Jun 05, 2011 at 04:12:11AM +0200, Carlos E. R. wrote:

...

I found a mis-feature of cronie:

If a user has a crontab entry that starts with a dash (meaning: don't log) the entire line is skipped. Existing crontab entries like that fail silently.

https://bugzilla.novell.com/show_bug.cgi?id=698549

and the other is:

...

The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."

But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).

https://bugzilla.novell.com/show_bug.cgi?id=698267 -- Vita Cizek